If you have a setjmp/longjmp situation, it's possible for stack slot coloring to
reuse a stack slot before it's really dead. For instance, if we have something
like this:
1: y = g;
x = sigsetjmp(env, 0);
switch (x) {
case 1:
/* ... */
goto run;
case 0:
run:
do_run(); /* marked as "no return" */
break;
case 3:
if (...) {
/* ... */
goto run;
}
/* ... */
break;
}
2: g = y;
"y" may be put onto the stack, so the expression "g = y" is relying upon the
fact that the stack slot containing "y" isn't modified between (1) and (2). But
it can be, because of the "no return" calls in there. A longjmp might come back
with 3, modify the stack slot, and then go to case 0. And it's perfectly
acceptable to reuse the stack slot there because there's no CFG flow from case 3
to (2).
The fix is to disable certain optimizations in these situations. Ideally, we'd
disable them for all "returns twice" functions. But we don't support that
attribute. Check for "setjmp" and "sigsetjmp" instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104640 91177308-0d34-0410-b5e6-96231b3b80d8
Mon Ping provided; unfortunately bugpoint failed to
reduce it, but I think it's important to have a test for
this in the suite. 8023512.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104624 91177308-0d34-0410-b5e6-96231b3b80d8
so that it will continue to test what it was meant to test when I commit a
separate change for better support of BUILD_VECTOR and VECTOR_SHUFFLE for Neon.
Fix a DAG combiner crash exposed by this test change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104380 91177308-0d34-0410-b5e6-96231b3b80d8
that are aliases of the specified register.
- Rename modifiesRegister to definesRegister since it's looking a def of the
specific register or one of its super-registers. It's not looking for def of a
sub-register or alias that could change the specified register.
- Added modifiesRegister to look for defs of aliases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104377 91177308-0d34-0410-b5e6-96231b3b80d8
reads or writes a register.
This takes partial redefines and undef uses into account.
Don't actually use it yet. That caused miscompiles.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104372 91177308-0d34-0410-b5e6-96231b3b80d8
definitions of the virtual register.
This happens when spilling the registers produced by REG_SEQUENCE:
%reg1047:5<def>, %reg1047:6<def>, %reg1047:7<def> = VLD3d8 %reg1033, 0, pred:14, pred:%reg0
The rewriter would spill the register multiple times, dead store elimination
tried to keep up, but ended up cutting the branch it was sitting on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104321 91177308-0d34-0410-b5e6-96231b3b80d8
<imp-def> operand for the full register. This ensures that the full physical
register is marked live after register allocation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104320 91177308-0d34-0410-b5e6-96231b3b80d8
pipeline stall. It's useful for targets like ARM cortex-a8. NEON has a lot
of long latency instructions so a strict register pressure reduction
scheduler does not work well.
Early experiments show this speeds up some NEON loops by over 30%.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104216 91177308-0d34-0410-b5e6-96231b3b80d8
test/Codegen/ARM/reg_sequence.ll but it doesn't affect the generated code
because the coalescer cleans it up. Radar 7998853.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104185 91177308-0d34-0410-b5e6-96231b3b80d8
A partial redef now triggers a reload if required. Also don't add
<imp-def,dead> operands for physical superregisters.
Kill flags are still treated as full register kills, and <imp-use,kill> operands
are added for physical superregisters as before.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104167 91177308-0d34-0410-b5e6-96231b3b80d8
