summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* Add a new DAGCombine optimization for BUILD_VECTOR.Nadav Rotem2011-10-291-0/+83
| | | | | | | If all of the inputs are zero/any_extended, create a new simple BV which can be further optimized by other BV optimizations. llvm-svn: 143297
* Revert r143206, as there are still some failing tests.Dan Gohman2011-10-294-436/+518
| | | | llvm-svn: 143262
* Reapply r143177 and r143179 (reverting r143188), with schedulerDan Gohman2011-10-284-518/+436
| | | | | | | | | fixes: Use a separate register, instead of SP, as the calling-convention resource, to avoid spurious conflicts with actual uses of SP. Also, fix unscheduling of calling sequences, which can be triggered by pseudo-two-address dependencies. llvm-svn: 143206
* Dwarf: [PR11022] Fix emitting DW_AT_const_value(>i64), to be ↵NAKAMURA Takumi2011-10-281-7/+9
| | | | | | | | | | | host-endian-neutral. Don't assume APInt::getRawData() would hold target-aware endianness nor host-compliant endianness. rawdata[0] holds most lower i64, even on big endian host. FIXME: Add a testcase for big endian target. FIXME: Ditto on CompileUnit::addConstantFPValue() ? llvm-svn: 143194
* Use BranchProbability compare operators.Benjamin Kramer2011-10-281-8/+3
| | | | llvm-svn: 143190
* Speculatively disable Dan's commits 143177 and 143179 to see ifDuncan Sands2011-10-284-407/+516
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | it fixes the dragonegg self-host (it looks like gcc is miscompiled). Original commit messages: Eliminate LegalizeOps' LegalizedNodes map and have it just call RAUW on every node as it legalizes them. This makes it easier to use hasOneUse() heuristics, since unneeded nodes can be removed from the DAG earlier. Make LegalizeOps visit the DAG in an operands-last order. It previously used operands-first, because LegalizeTypes has to go operands-first, and LegalizeTypes used to be part of LegalizeOps, but they're now split. The operands-last order is more natural for several legalization tasks. For example, it allows lowering code for nodes with floating-point or vector constants to see those constants directly instead of seeing the lowered form (often constant-pool loads). This makes some things somewhat more complicated today, though it ought to allow things to be simpler in the future. It also fixes some bugs exposed by Legalizing using RAUW aggressively. Remove the part of LegalizeOps that attempted to patch up invalid chain operands on libcalls generated by LegalizeTypes, since it doesn't work with the new LegalizeOps traversal order. Instead, define what LegalizeTypes is doing to be correct, and transfer the responsibility of keeping calls from having overlapping calling sequences into the scheduler. Teach the scheduler to model callseq_begin/end pairs as having a physical register definition/use to prevent calls from having overlapping calling sequences. This is also somewhat complicated, though there are ways it might be simplified in the future. This addresses rdar://9816668, rdar://10043614, rdar://8434668, and others. Please direct high-level questions about this patch to management. Delete #if 0 code accidentally left in. llvm-svn: 143188
* Always use the string pool, even when it makes the .o larger. This may helpNick Lewycky2011-10-283-60/+11
| | | | | | | tools that read the debug info in the .o files by making the DIE sizes more consistent. llvm-svn: 143186
* Delete #if 0 code accidentally left in.Dan Gohman2011-10-281-17/+0
| | | | llvm-svn: 143179
* Eliminate LegalizeOps' LegalizedNodes map and have it just call RAUWDan Gohman2011-10-284-515/+423
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | on every node as it legalizes them. This makes it easier to use hasOneUse() heuristics, since unneeded nodes can be removed from the DAG earlier. Make LegalizeOps visit the DAG in an operands-last order. It previously used operands-first, because LegalizeTypes has to go operands-first, and LegalizeTypes used to be part of LegalizeOps, but they're now split. The operands-last order is more natural for several legalization tasks. For example, it allows lowering code for nodes with floating-point or vector constants to see those constants directly instead of seeing the lowered form (often constant-pool loads). This makes some things somewhat more complicated today, though it ought to allow things to be simpler in the future. It also fixes some bugs exposed by Legalizing using RAUW aggressively. Remove the part of LegalizeOps that attempted to patch up invalid chain operands on libcalls generated by LegalizeTypes, since it doesn't work with the new LegalizeOps traversal order. Instead, define what LegalizeTypes is doing to be correct, and transfer the responsibility of keeping calls from having overlapping calling sequences into the scheduler. Teach the scheduler to model callseq_begin/end pairs as having a physical register definition/use to prevent calls from having overlapping calling sequences. This is also somewhat complicated, though there are ways it might be simplified in the future. This addresses rdar://9816668, rdar://10043614, rdar://8434668, and others. Please direct high-level questions about this patch to management. llvm-svn: 143177
* Teach our Dwarf emission to use the string pool.Nick Lewycky2011-10-276-39/+56
| | | | llvm-svn: 143097
* Don't crash on 128-bit sdiv by constant. Found by inspection.Eli Friedman2011-10-271-9/+6
| | | | llvm-svn: 143095
* Rename NonScalarIntSafe to something more appropriate.Lang Hames2011-10-261-4/+4
| | | | llvm-svn: 143080
* Reflow lines, fix comments for doxygen style, fix whitespace. No functionalityNick Lewycky2011-10-262-34/+27
| | | | | | change. llvm-svn: 143074
* Simplify SplitVecRes_UnaryOp by removing all the code that isDuncan Sands2011-10-261-43/+5
| | | | | | | | | | | | | | | | | | | | trying to legalize the operand types when only the result type is required to be legalized - the type legalization machinery will get round to the operands later if they need legalizing. There can be a point to legalizing operands in parallel with the result: when this saves compile time or results in better code. There was only one case in which this was true: when the operand is also split, so keep the logic for that bit. As a result of this change, additional operand legalization methods may need to be introduced to handle nodes where the result and operand types can differ, like SIGN_EXTEND, but the testsuite doesn't contain any tests where this is the case. In any case, it seems better to require such methods (and die with an assert if they doesn't exist) than to quietly produce wrong code if we forgot to special case the node in SplitVecRes_UnaryOp. llvm-svn: 143026
* Don't use floating point to do an integer's job.Jakob Stoklund Olesen2011-10-261-4/+7
| | | | | | | | | | | This code makes different decisions when compiled into x87 instructions because of different rounding behavior. That caused phase 2/3 miscompares on 32-bit Linux when the phase 1 compiler was built with gcc (using x87), and the phase 2 compiler was built with clang (using SSE). This fixes PR11200. llvm-svn: 143006
* Disable LICM speculation in high register pressure situation again now that ↵Evan Cheng2011-10-261-1/+1
| | | | | | Devang has fixed other issues. llvm-svn: 143003
* Reapply r142920 with fix:Bill Wendling2011-10-261-0/+3
| | | | | | | | | | | | An MBB which branches to an EH landing pad shouldn't be considered for tail merging. In SjLj EH, the jump to the landing pad is not done explicitly through a branch statement. The EH landing pad is added as a successor to the throwing BB. Because of that however, the branch folding pass could mistakenly think that it could merge the throwing BB with another BB. This isn't safe to do. <rdar://problem/10334833> llvm-svn: 143001
* Remove a couple redundant checks.Eli Friedman2011-10-251-2/+0
| | | | llvm-svn: 142959
* Make assert() message more informative.Jim Grosbach2011-10-251-1/+2
| | | | | | PR11217. llvm-svn: 142956
* Revert commit 142891. Takumi bisected the tablegen miscompilesDuncan Sands2011-10-251-2/+1
| | | | | | | | | | | | | | down to this commit. Original commit message: An MBB which branches to an EH landing pad shouldn't be considered for tail merging. In SjLj EH, the jump to the landing pad is not done explicitly through a branch statement. The EH landing pad is added as a successor to the throwing BB. Because of that however, the branch folding pass could mistakenly think that it could merge the throwing BB with another BB. This isn't safe to do. <rdar://problem/10334833> llvm-svn: 142920
* Remove dead enum value. There is no DIESectionOffset.Nick Lewycky2011-10-251-1/+0
| | | | llvm-svn: 142912
* Remove unused forward decl.Eric Christopher2011-10-251-1/+0
| | | | llvm-svn: 142892
* An MBB which branches to an EH landing pad shouldn't be considered for tail ↵Bill Wendling2011-10-251-1/+2
| | | | | | | | | | | | merging. In SjLj EH, the jump to the landing pad is not done explicitly through a branch statement. The EH landing pad is added as a successor to the throwing BB. Because of that however, the branch folding pass could mistakenly think that it could merge the throwing BB with another BB. This isn't safe to do. <rdar://problem/10334833> llvm-svn: 142891
* Check the visibility of the global variable before placing it into the stubsBill Wendling2011-10-241-2/+6
| | | | | | | table. A hidden variable could potentially end up in both lists. <rdar://problem/10336715> llvm-svn: 142869
* Really unbreak CMake buildDouglas Gregor2011-10-241-3/+1
| | | | llvm-svn: 142822
* Unbreak CMake buildDouglas Gregor2011-10-241-0/+1
| | | | llvm-svn: 142821
* 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-241-4/+4
| | | | | | use of Sched::ILP instead, as Sched::Latency is going away. llvm-svn: 142813
* Change the default scheduler from Latency to ILP, since LatencyDan Gohman2011-10-241-1/+1
| | | | | | is going away. llvm-svn: 142810
* 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
* 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
* 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
* 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
* Fix pr11194. When promoting and splitting integers we need to useNadav Rotem2011-10-211-3/+12
| | | | | | | | ZExtPromotedInteger and SExtPromotedInteger based on the operation we legalize. SetCC return type needs to be legalized via PromoteTargetBoolean. llvm-svn: 142660
* 1. Fix the widening of SETCC in WidenVecOp_SETCC. Use the correct return CC ↵Nadav Rotem2011-10-213-14/+17
| | | | | | | | type. 2. Fix a typo in CONCAT_VECTORS which exposed the bug in #1. llvm-svn: 142648
* Add loop aligning to MachineBlockPlacement based on review discussion soChandler Carruth2011-10-211-3/+39
| | | | | | | | | | | | | | | | | | | it's a bit more plausible to use this instead of CodePlacementOpt. The code for this was shamelessly stolen from CodePlacementOpt, and then trimmed down a bit. There doesn't seem to be much utility in returning true/false from this pass as we may or may not have rewritten all of the blocks. Also, the statistic of counting how many loops were aligned doesn't seem terribly important so I removed it. If folks would like it to be included, I'm happy to add it back. This was probably the most egregious of the missing features, and now I'm going to start gathering some performance numbers and looking at specific loop structures that have different layout between the two. Test is updated to include both basic loop alignment and nested loop alignment. llvm-svn: 142645
* Implement a block placement pass based on the branch probability andChandler Carruth2011-10-214-2/+638
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | block frequency analyses. This differs substantially from the existing block-placement pass in LLVM: 1) It operates on the Machine-IR in the CodeGen layer. This exposes much more (and more precise) information and opportunities. Also, the results are more stable due to fewer transforms ocurring after the pass runs. 2) It uses the generalized probability and frequency analyses. These can model static heuristics, code annotation derived heuristics as well as eventual profile loading. By basing the optimization on the analysis interface it can work from any (or a combination) of these inputs. 3) It uses a more aggressive algorithm, both building chains from tho bottom up to maximize benefit, and using an SCC-based walk to layout chains of blocks in a profitable ordering without O(N^2) iterations which the old pass involves. The pass is currently gated behind a flag, and not enabled by default because it still needs to grow some important features. Most notably, it needs to support loop aligning and careful layout of loop structures much as done by hand currently in CodePlacementOpt. Once it supports these, and has sufficient testing and quality tuning, it should replace both of these passes. Thanks to Nick Lewycky and Richard Smith for help authoring & debugging this, and to Jakob, Andy, Eric, Jim, and probably a few others I'm forgetting for reviewing and answering all my questions. Writing a backend pass is *sooo* much better now than it used to be. =D llvm-svn: 142641
* Remove a now dead function, fixing -Wunused-function warnings fromChandler Carruth2011-10-211-20/+0
| | | | | | Clang. llvm-svn: 142631
* Delete the list-tdrr scheduler. Top-down schedulers are going awayDan Gohman2011-10-201-203/+11
| | | | | | because they don't support physical register dependencies. llvm-svn: 142620
* Revert r142579, "Fix a type in the legalization of CONCAT_VECTORS". This is Chad Rosier2011-10-201-1/+1
| | | | | | | causing one of the unit tests to infinitely loop, which resulted in the buildbots stalling. llvm-svn: 142604
* As Evan suggested, loads from constant pool are safe to speculate.Devang Patel2011-10-201-5/+5
| | | | llvm-svn: 142593
* Add a comment.Devang Patel2011-10-201-1/+3
| | | | llvm-svn: 142592
* Fix a type in the legalization of CONCAT_VECTORS.Nadav Rotem2011-10-201-1/+1
| | | | llvm-svn: 142579
* Improve code generation for vselect on SSE2:Nadav Rotem2011-10-191-7/+9
| | | | | | | | | When checking the availability of instructions using the TLI, a 'promoted' instruction IS available. It means that the value is bitcasted to another type for which there is an operation. The correct check for the availablity of an instruction is to check if it should be expanded. llvm-svn: 142542
* Add support for the vector-widening of vselect and vector-setccNadav Rotem2011-10-192-1/+28
| | | | llvm-svn: 142488
* Missed a spot!Nick Lewycky2011-10-181-1/+1
| | | | llvm-svn: 142436
* Fix some typo/formatting issues. No functionality change.Nick Lewycky2011-10-182-10/+10
| | | | llvm-svn: 142435
OpenPOWER on IntegriCloud