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.
llvm-svn: 104640
are st(0). These can be encoded using an opcode for storing in st(0) or using
an opcode for storing in st(i), where i can also be 0. To allow testing with
the darwin assembler and get a matching binary the opcode for storing in st(0)
is now used. To do this the same logical trick is use from the darwin assembler
in converting things like this:
fmul %st(0), %st
into this:
fmul %st(0)
by looking for the second operand being X86::ST0 for specific floating point
mnemonics then removing the second X86::ST0 operand. This also has the add
benefit to allow things like:
fmul %st(1), %st
that llvm-mc did not assemble.
llvm-svn: 104634
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.
llvm-svn: 104624
This passes lit tests, but I'll give it a go through the buildbots to smoke out
any remaining places that depend on the old SubRegIndex numbering.
Then I'll remove NumberHack entirely.
llvm-svn: 104615
Thumb2 ADD and SUB instructions: allow RSB instructions be changed to set the
condition codes, and allow RSBS instructions to be predicated.
llvm-svn: 104582
structure that represents a mapping without any dependencies on SubRegIndex
numbering.
This brings us closer to being able to remove the explicit SubRegIndex
numbering, and it is now possible to specify any mapping without inventing
*_INVALID register classes.
llvm-svn: 104563
This is the beginning of purely symbolic subregister indices, but we need a bit
of jiggling before the explicit numeric indices can be completely removed.
llvm-svn: 104492
bugpoint does "Running the code generator to test for a crash" this
gets you a crash if llc goes into an infinite loop or uses up vast
amounts of memory.
llvm-svn: 104485