- Oct 18, 2011
-
-
Bill Wendling authored
Use the custom inserter for the ARM setjmp intrinsics. Instead of creating the SjLj dispatch table in IR, where it frequently violates serveral assumptions -- in particular assumptions made by the landingpad instruction about what can branch to a landing pad and what cannot. Performing this in the back-end allows us to violate these assumptions without the IR getting angry at us. It also allows us to perform a small optimization. We can shove the address of the dispatch's basic block into the function context and not have to add code around the setjmp to check for the return value and jump to the dispatch. Neat, huh? <rdar://problem/10116753> llvm-svn: 142294
-
- Oct 17, 2011
-
-
Cameron Zwarich authored
to match its final use. With this change, all of test-suite compiles for Thumb2 with -verify-coalescing enabled. llvm-svn: 142287
-
-
Bill Wendling authored
Some code want to check that *any* call within a function has the 'returns twice' attribute, not just that the current function has one. llvm-svn: 142221
-
Bill Wendling authored
obsolete. Check the attribute instead. <rdar://problem/8031714> llvm-svn: 142212
-
Chad Rosier authored
Patch by Joe Abbey <jabbey@arxan.com>. llvm-svn: 142206
-
Devang Patel authored
Radar 10281206. llvm-svn: 142202
-
- Oct 16, 2011
-
-
Nadav Rotem authored
Changed tests which assumed that vectors are legalized by widening them. llvm-svn: 142152
-
Benjamin Kramer authored
While at it, merge some format strings. llvm-svn: 142140
-
Benjamin Kramer authored
llvm-svn: 142139
-
- Oct 15, 2011
-
-
Nadav Rotem authored
cases we need the second type-legalization pass in order to support all cases. llvm-svn: 142060
-
Bill Wendling authored
This isn't put into the 'clear()' method because the information needs to stick around (at least for a little bit) after the selection DAG is built. llvm-svn: 142032
-
- Oct 14, 2011
-
-
Evan Cheng authored
llvm-svn: 141988
-
Jakob Stoklund Olesen authored
Fixes PR10814. Patch by Jan Sjödin! llvm-svn: 141960
-
Jim Grosbach authored
Pointed out by George Russell. llvm-svn: 141956
-
Jakob Stoklund Olesen authored
When spilling around an instruction with a dead def, remember to add a value number for the def. The missing value number wouldn't normally create problems since there would be an incoming live range as well. However, due to another bug we could spill a dead V_SET0 instruction which doesn't read any values. The missing value number caused an empty live range to be created which is dangerous since it doesn't interfere with anything. This fixes part of PR11125. llvm-svn: 141923
-
- Oct 13, 2011
-
-
Eric Christopher authored
looking at. llvm-svn: 141892
-
Cameron Zwarich authored
llvm-svn: 141855
-
Nick Lewycky authored
have the same address as the one we deleted, and we don't want that in the set yet. Noticed by inspection. llvm-svn: 141849
-
Nick Lewycky authored
llvm-svn: 141844
-
Nick Lewycky authored
llvm-svn: 141842
-
Jakob Stoklund Olesen authored
Now that MI->getRegClassConstraint() can also handle inline assembly, don't bail when recomputing the register class of a virtual register used by inline asm. This fixes PR11078. llvm-svn: 141836
-
Jakob Stoklund Olesen authored
Most instructions have some requirements for their register operands. Usually, this is expressed as register class constraints in the MCInstrDesc, but for inline assembly the constraints are encoded in the flag words. llvm-svn: 141835
-
Jakob Stoklund Olesen authored
llvm-svn: 141834
-
Jakob Stoklund Olesen authored
The inline asm operand constraint is initially encoded in the virtual register for the operand, but that register class may change during coalescing, and the original constraint is lost. Encode the original register class as part of the flag word for each inline asm operand. This makes it possible to recover the actual constraint required by inline asm, just like we can for normal instructions. llvm-svn: 141833
-
Bill Wendling authored
our current machine instruction defines a register with the same register class as what's being replaced. This showed up in the SPEC 403.gcc benchmark, where it would ICE because a tail call was expecting one register class but was given another. (The machine instruction verifier catches this situation.) <rdar://problem/10270968> llvm-svn: 141830
-
Eli Friedman authored
Use a utility from MathExtras to clarify a check and avoid undefined behavior. Based on patch by Ahmed Charles. llvm-svn: 141829
-
- Oct 12, 2011
-
-
Evan Cheng authored
Disable machine LICM speculation check (for profitability) until I have time to investigate the regressions. llvm-svn: 141813
-
Cameron Zwarich authored
rather than the previous index. If a block has a single instruction, the previous index may be in a different basic block. I have no clue how this used to work on all of test-suite, because now this failure is seen quite often when trying to compile code with -strong-phi-elim. This fixes PR10252. llvm-svn: 141812
-
Dan Gohman authored
intended, but only by accident. llvm-svn: 141779
-
Bill Wendling authored
containing loop's header to see if that's a landing pad. If it is, then we don't want to hoist instructions out of the loop and above the header. llvm-svn: 141767
-
Jakob Stoklund Olesen authored
llvm-svn: 141763
-
Evan Cheng authored
1. The speculation check may not have been performed if the BB hasn't had a load LICM candidate. 2. If the candidate would be CSE'ed, then go ahead and speculatively LICM the instruction even if it's in high register pressure situation. llvm-svn: 141747
-
Evan Cheng authored
Also teach MachineLICM to avoid "speculation" when register pressure is high. llvm-svn: 141744
-
Eric Christopher authored
file. Since it should only be used when necessary propagate it through the backend code generation and tweak testcases accordingly. This helps with code like in clang's test/CodeGen/debug-info-line.c where we have multiple #line directives within a single lexical block and want to generate only a single block that contains each file change. Part of rdar://10246360 llvm-svn: 141729
-
Eric Christopher authored
llvm-svn: 141728
-
Bill Wendling authored
The blocks with invokes have branches to the dispatch block, because that more correctly models the behavior of the CFG. The dispatch of course has edges to the landing pads. Those landing pads could contain invokes, which then have branches back to the dispatch. This creates a loop. The machine LICM pass looks at this loop and thinks it can hoist elements out of it. But because the dispatch is an alternate entry point into the program, the hoisted instructions won't be executed. I wasn't able to get a testcase which was small and could reproduce all of the time. The function_try_block.cpp in llvm-test was where this showed up. llvm-svn: 141726
-
- Oct 11, 2011
-
-
Devang Patel authored
For example, MachineLICM should not hoist a load that is not guaranteed to be executed. Radar 10254254. llvm-svn: 141689
-
Nadav Rotem authored
llvm-svn: 141667
-
Nadav Rotem authored
Add support for legalization of vector trunc-store where the saved scalar type is illegal (for example, v2i16 on systems where the smallest store size is i32) llvm-svn: 141661
-