summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* Really unbreak CMake buildDouglas Gregor2011-10-241-3/+1
| | | | llvm-svn: 142822
* Unbreak CMake buildDouglas Gregor2011-10-241-0/+1
| | | | llvm-svn: 142821
* Fix a NEON disassembly case that was broken in the recent refactorings. As ↵Owen Anderson2011-10-241-6/+0
| | | | | | more of this code gets refactored, a lot of these manual decoding hooks should get smaller and/or go away entirely. llvm-svn: 142817
* Delete the top-down "Latency" scheduler. Top-down scheduling doesn't handleDan Gohman2011-10-241-265/+0
| | | | | | | physreg dependencies, and upcoming codegen changes will require proper physreg dependence handling. llvm-svn: 142816
* Delete the Latency scheduling preference.Dan Gohman2011-10-241-2/+0
| | | | llvm-svn: 142815
* Change this overloaded use of Sched::Latency to be an overloadedDan Gohman2011-10-242-6/+6
| | | | | | use of Sched::ILP instead, as Sched::Latency is going away. llvm-svn: 142813
* Remove the explicit request for "Latency" scheduling from MSP430,Dan Gohman2011-10-241-1/+0
| | | | | | as the Latency scheduler is going away. llvm-svn: 142811
* Change the default scheduler from Latency to ILP, since LatencyDan Gohman2011-10-241-1/+1
| | | | | | is going away. llvm-svn: 142810
* Thumb2 LDM instructions can target PC. Make sure to encode it.Jim Grosbach2011-10-241-8/+4
| | | | | | PR11220 llvm-svn: 142801
* Cleanup. Get rid of the old SjLj EH lowering code. No functionality change.Bill Wendling2011-10-241-584/+10
| | | | llvm-svn: 142800
* Sink an otherwise unused variable's initializer into the asserts thatChandler Carruth2011-10-241-3/+2
| | | | | | used it. Fixes an unused variable warning from GCC on release builds. llvm-svn: 142799
* Remove return heuristics from the static branch probabilities, andChandler Carruth2011-10-241-73/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | introduce no-return or unreachable heuristics. The return heuristics from the Ball and Larus paper don't work well in practice as they pessimize early return paths. The only good hitrate return heuristics are those for: - NULL return - Constant return - negative integer return Only the last of these three can possibly require significant code for the returning block, and even the last is fairly rare and usually also a constant. As a consequence, even for the cold return paths, there is little code on that return path, and so little code density to be gained by sinking it. The places where sinking these blocks is valuable (inner loops) will already be weighted appropriately as the edge is a loop-exit branch. All of this aside, early returns are nearly as common as all three of these return categories, and should actually be predicted as taken! Rather than muddy the waters of the static predictions, just remain silent on returns and let the CFG itself dictate any layout or other issues. However, the return heuristic was flagging one very important case: unreachable. Unfortunately it still gave a 1/4 chance of the branch-to-unreachable occuring. It also didn't do a rigorous job of finding those blocks which post-dominate an unreachable block. This patch builds a more powerful analysis that should flag all branches to blocks known to then reach unreachable. It also has better worst-case runtime complexity by not looping through successors for each block. The previous code would perform an N^2 walk in the event of a single entry block branching to N successors with a switch where each successor falls through to the next and they finally fall through to a return. Test case added for noreturn heuristics. Also doxygen comments improved along the way. llvm-svn: 142793
* Reapply r142781 with fix. Original message:Nick Lewycky2011-10-241-20/+32
| | | | | | | | | | | | | | | | | | | Enhance SCEV's brute force loop analysis to handle multiple PHI nodes in the loop header when computing the trip count. With this, we now constant evaluate: struct ListNode { const struct ListNode *next; int i; }; static const struct ListNode node1 = {0, 1}; static const struct ListNode node2 = {&node1, 2}; static const struct ListNode node3 = {&node2, 3}; int test() { int sum = 0; for (const struct ListNode *n = &node3; n != 0; n = n->next) sum += n->i; return sum; } llvm-svn: 142790
* PHI nodes not in the loop header aren't part of the loop iteration initialNick Lewycky2011-10-241-1/+1
| | | | | | | state. Furthermore, they might not have two operands. This fixes the underlying issue behind the crashes introduced in r142781. llvm-svn: 142788
* A dead malloc, a free(NULL) and a free(undef) are all trivially deadNick Lewycky2011-10-241-0/+8
| | | | | | | | | | instructions. This doesn't introduce any optimizations we weren't doing before (except potentially due to pass ordering issues), now passes will eliminate them sooner as part of their own cleanups. llvm-svn: 142787
* Speculatively revert r142781. Bots are showingNick Lewycky2011-10-241-32/+20
| | | | | | | Assertion `i_nocapture < OperandTraits<PHINode>::operands(this) && "getOperand() out of range!"' failed. coming out of indvars. llvm-svn: 142786
* Windows/Path.inc: [PR8460] Get rid of ScopedNullTerminator. Thanks to Zvi ↵NAKAMURA Takumi2011-10-241-18/+9
| | | | | | Rackover! llvm-svn: 142785
* Simplify the design of BranchProbabilityInfo by collapsing it intoChandler Carruth2011-10-241-135/+90
| | | | | | | | | | | | | a single class. Previously it was split between two classes, one internal and one external. The concern seemed to center around exposing the weights used, but those can remain confined to the implementation file. Having a single class to maintain the state and analyses in use will also simplify several of the enhancements I want to make to our static heuristics. llvm-svn: 142783
* Enhance SCEV's brute force loop analysis to handle multiple PHI nodes in theNick Lewycky2011-10-231-20/+32
| | | | | | | | | | | | | | | | | | loop header when computing the trip count. With this, we now constant evaluate: struct ListNode { const struct ListNode *next; int i; }; static const struct ListNode node1 = {0, 1}; static const struct ListNode node2 = {&node1, 2}; static const struct ListNode node3 = {&node2, 3}; int test() { int sum = 0; for (const struct ListNode *n = &node3; n != 0; n = n->next) sum += n->i; return sum; } llvm-svn: 142781
* Tidy up a loop to be more idiomatic for LLVM's codebase, and remove someChandler Carruth2011-10-231-18/+9
| | | | | | | extraneous whitespace. Trying to clean-up this pass as much as I can before I start making functional changes. llvm-svn: 142780
* Add X86 SARX, SHRX, and SHLX instructions.Craig Topper2011-10-231-18/+32
| | | | llvm-svn: 142779
* Teach the BranchProbabilityInfo pass to print its results, and use thatChandler Carruth2011-10-231-2/+20
| | | | | | | | | | to bring it under direct test instead of merely indirectly testing it in the BlockFrequencyInfo pass. The next step is to start adding tests for the various heuristics employed, and to start fixing those heuristics once they're under test. llvm-svn: 142778
* Now that we have comparison on probabilities, add some static functionsChandler Carruth2011-10-231-8/+5
| | | | | | | to get important constant branch probabilities and use them for finding the best branch out of a set of possibilities. llvm-svn: 142762
* Remove a commented out line of code that snuck by my auditing.Chandler Carruth2011-10-231-1/+0
| | | | llvm-svn: 142761
* Print branch probabilities as percentages.Benjamin Kramer2011-10-231-3/+3
| | | | | | 50% is much more readable than 5.000000e-01. llvm-svn: 142752
* Add compare operators to BranchProbability and use it to determine if an ↵Benjamin Kramer2011-10-232-15/+4
| | | | | | edge is hot. llvm-svn: 142751
* Completely re-write the algorithm behind MachineBlockPlacement based onChandler Carruth2011-10-231-399/+227
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | discussions with Andy. Fundamentally, the previous algorithm is both counter productive on several fronts and prioritizing things which aren't necessarily the most important: static branch prediction. The new algorithm uses the existing loop CFG structure information to walk through the CFG itself to layout blocks. It coalesces adjacent blocks within the loop where the CFG allows based on the most likely path taken. Finally, it topologically orders the block chains that have been formed. This allows it to choose a (mostly) topologically valid ordering which still priorizes fallthrough within the structural constraints. As a final twist in the algorithm, it does violate the CFG when it discovers a "hot" edge, that is an edge that is more than 4x hotter than the competing edges in the CFG. These are forcibly merged into a fallthrough chain. Future transformations that need te be added are rotation of loop exit conditions to be fallthrough, and better isolation of cold block chains. I'm also planning on adding statistics to model how well the algorithm does at laying out blocks based on the probabilities it receives. The old tests mostly still pass, and I have some new tests to add, but the nested loops are still behaving very strangely. This almost seems like working-as-intended as it rotated the exit branch to be fallthrough, but I'm not convinced this is actually the best layout. It is well supported by the probabilities for loops we currently get, but those are pretty broken for nested loops, so this may change later. llvm-svn: 142743
* Add X86 RORX instructionCraig Topper2011-10-235-0/+36
| | | | llvm-svn: 142741
* The element insertion code in scalar replacement doesn't handle incorrectCameron Zwarich2011-10-231-2/+4
| | | | | | | element types, even though the element extraction code does. It is surprising that this bug has been here for so long. Fixes <rdar://problem/10318778>. llvm-svn: 142740
* Add X86 MULX instruction for disassembler.Craig Topper2011-10-231-0/+24
| | | | llvm-svn: 142738
* Remove some duplicate specifying of neverHasSideEffects and mayLoad from X86 ↵Craig Topper2011-10-221-5/+5
| | | | | | multiply instructions. llvm-svn: 142737
* A non-escaping malloc in the entry block is not unlike an alloca. Do dead-storeNick Lewycky2011-10-221-2/+25
| | | | | | elimination on them too. llvm-svn: 142735
* Make SCEV's brute force analysis stronger in two ways. Firstly, we should beNick Lewycky2011-10-221-26/+145
| | | | | | | | | | | | | | | | able to constant fold load instructions where the argument is a constant. Second, we should be able to watch multiple PHI nodes through the loop; this patch only supports PHIs in loop headers, more can be done here. With this patch, we now constant evaluate: static const int arr[] = {1, 2, 3, 4, 5}; int test() { int sum = 0; for (int i = 0; i < 5; ++i) sum += arr[i]; return sum; } llvm-svn: 142731
* Move various generated tables into read-only memory, fixing up const ↵Benjamin Kramer2011-10-223-11/+12
| | | | | | correctness along the way. llvm-svn: 142726
* Fix pr11193.Nadav Rotem2011-10-221-3/+0
| | | | | | | SHL inserts zeros from the right, thus even when the original sign_extend_inreg value was of 1-bit, we need to sra. llvm-svn: 142724
* The different flavors of ARM have different valid subsets of registers. CheckBill Wendling2011-10-221-3/+13
| | | | | | | that the set of callee-saved registers is correct for the specific platform. <rdar://problem/10313708> & ctor_dtor_count & ctor_dtor_count-2 llvm-svn: 142706
* Assembly parsing for 4-register sequential variant of VLD2.Jim Grosbach2011-10-213-36/+18
| | | | llvm-svn: 142704
* Assembly parsing for 2-register sequential variant of VLD2.Jim Grosbach2011-10-214-30/+46
| | | | llvm-svn: 142691
* Make sure that the landing pads themselves have no PHI instructions in them.Bill Wendling2011-10-211-0/+21
| | | | | | | | The assumption in the back-end is that PHIs are not allowed at the start of the landing pad block for SjLj exceptions. <rdar://problem/10313708> llvm-svn: 142689
* Extend the floating point heuristic to consider NaN checks unlikely.Benjamin Kramer2011-10-211-4/+17
| | | | llvm-svn: 142687
* Remap blockaddress correctly when inlining a function. Fixes PR10162.Eli Friedman2011-10-211-1/+32
| | | | llvm-svn: 142684
* Use LLVMBool for a function that logically returns a boolean value.Owen Anderson2011-10-211-1/+1
| | | | llvm-svn: 142683
* Assembly parsing for 4-register variant of VLD1.Jim Grosbach2011-10-216-31/+38
| | | | llvm-svn: 142682
* BranchProbabilityInfo: floating point equality is unlikely.Benjamin Kramer2011-10-211-2/+34
| | | | | | This is from the same paper from Ball and Larus as the rest of the currently implemented heuristics. llvm-svn: 142677
* Assembly parsing for 3-register variant of VLD1.Jim Grosbach2011-10-216-22/+37
| | | | llvm-svn: 142675
* STABS symbols are debug symbols.Owen Anderson2011-10-211-1/+3
| | | | llvm-svn: 142673
* Minor simplification: use ShuffleVectorInst::getMaskValue instead of a more ↵Eli Friedman2011-10-211-2/+2
| | | | | | expensive helper. llvm-svn: 142672
* Extend instcombine's shufflevector simplification to handle more cases where ↵Eli Friedman2011-10-211-61/+195
| | | | | | the input and output vectors have different sizes. Patch by Xiaoyi Guo. llvm-svn: 142671
* ARM VLD parsing and encoding.Jim Grosbach2011-10-216-247/+276
| | | | | | | | | | | | Next step in the ongoing saga of NEON load/store assmebly parsing. Handle VLD1 instructions that take a two-register register list. Adjust the instruction definitions to only have the single encoded register as an operand. The super-register from the pseudo is kept as an implicit def, so passes which come after pseudo-expansion still know that the instruction defines the other subregs. llvm-svn: 142670
* Don't automatically set the "fc" bits on MSR instructions if the user didn't ↵Owen Anderson2011-10-211-3/+7
| | | | | | ask for them. This is a divergence from gas' behavior, but it is correct per the documentation and allows us to forge ahead with roundtrip testing. llvm-svn: 142669
OpenPOWER on IntegriCloud