aboutsummaryrefslogtreecommitdiff
path: root/lib/CodeGen
AgeCommit message (Collapse)Author
2011-11-16Process all uses first before defs to accurately capture register liveness. ↵Evan Cheng
rdar://10449480 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144770 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-16CONCAT_VECTORS can have more than two operands. PR11389.Eli Friedman
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144768 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-16Add a couple asserts so it will be easier to debug if we accidentally pass ↵Eli Friedman
indexed loads/stores to the legalizer. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144767 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-16Rename MVT::untyped to MVT::Untyped to match similar nomenclature.Owen Anderson
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144747 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-15Stabilize the output of the dwarf accelerator tables. Fixes a comparisonEric Christopher
failure during bootstrap with it turned on. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144731 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-15GEPs with all zero indices are trivially coalesced by fast-isel. For example,Chad Rosier
%arrayidx135 = getelementptr inbounds [4 x [4 x [4 x [4 x i32]]]]* %M0, i32 0, i64 0 %arrayidx136 = getelementptr inbounds [4 x [4 x [4 x i32]]]* %arrayidx135, i32 0, i64 %idxprom134 Prior to this commit, the GEP instruction that defines %arrayidx136 thought that %arrayidx135 was a trivial kill. The GEP that defines %arrayidx135 doesn't generate any code and thus %M0 gets folded into the second GEP. Thus, we need to look through GEPs with all zero indices. rdar://10443319 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144730 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-15Added custom lowering for load->dec->store sequence in x86 when the EFLAGS ↵Pete Cooper
registers is used by later instructions. Only done for DEC64m right now. Fixes <rdar://problem/6172640> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144705 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-15Insert modified DBG_VALUE into LiveDbgValueMap. Devang Patel
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144696 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-15We currently use a callback to handle an IL pass deleting a BB that stillRafael Espindola
has a reference to it. Unfortunately, that doesn't work for codegen passes since we don't get notified of MBB's being deleted (the original BB stays). Use that fact to our advantage and after printing a function, check if any of the IL BBs corresponds to a symbol that was not printed. This fixes pr11202. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144674 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-15Remove all remaining uses of Value::getNameStr().Benjamin Kramer
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144648 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-15Twinify GraphWriter a little bit.Benjamin Kramer
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144647 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-15Check all overlaps when looking for used registers.Jakob Stoklund Olesen
A function using any RC alias is enough to enable the ExeDepsFix pass. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144636 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-15Make use of MachinePointerInfo::getFixedStack.Jay Foad
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144635 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-15Remove some unnecessary includes of PseudoSourceValue.h.Jay Foad
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144634 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-15Set SeenStore to true to prevent loads from being moved; also eliminates a ↵Evan Cheng
non-deterministic behavior. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144628 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-15Rather than trying to use the loop block sequence *or* the functionChandler Carruth
block sequence when recovering from unanalyzable control flow constructs, *always* use the function sequence. I'm not sure why I ever went down the path of trying to use the loop sequence, it is fundamentally not the correct sequence to use. We're trying to preserve the incoming layout in the cases of unreasonable control flow, and that is only encoded at the function level. We already have a filter to select *exactly* the sub-set of blocks within the function that we're trying to form into a chain. The resulting code layout is also significantly better because of this. In several places we were ending up with completely unreasonable control flow constructs due to the ordering chosen by the loop structure for its internal storage. This change removes a completely wasteful vector of basic blocks, saving memory allocation in the common case even though it costs us CPU in the fairly rare case of unnatural loops. Finally, it fixes the latest crasher reduced out of GCC's single source. Thanks again to Benjamin Kramer for the reduction, my bugpoint skills failed at it. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144627 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-15Break false dependencies before partial register updates.Jakob Stoklund Olesen
Two new TargetInstrInfo hooks lets the target tell ExecutionDepsFix about instructions with partial register updates causing false unwanted dependencies. The ExecutionDepsFix pass will break the false dependencies if the updated register was written in the previoius N instructions. The small loop added to sse-domains.ll runs twice as fast with dependency-breaking instructions inserted. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144602 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-15Track register ages more accurately.Jakob Stoklund Olesen
Keep track of the last instruction to define each register individually instead of per DomainValue. This lets us track more accurately when a register was last written. Also track register ages across basic blocks. When entering a new basic block, use the least stale predecessor def as a worst case estimate for register age. The register age is used to arbitrate between conflicting domains. The most recently defined register wins. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144601 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-14Avoid dereferencing off the beginning of lists.Evan Cheng
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144569 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-14At -O0, multiple uses of a virtual registers in the same BB are being markedEvan Cheng
"kill". This looks like a bug upstream. Since that's going to take some time to understand, loosen the assertion and disable the optimization when multiple kills are seen. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144568 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-14Teach two-address pass to re-schedule two-address instructions (or the killEvan Cheng
instructions of the two-address operands) in order to avoid inserting copies. This fixes the few regressions introduced when the two-address hack was disabled (without regressing the improvements). rdar://10422688 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144559 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-14Fix early-clobber handling in shrinkToUses.Jakob Stoklund Olesen
I broke this in r144515, it affected most ARM testers. <rdar://problem/10441389> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144547 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-14It helps to deallocate memory as well as allocate it. =] This actuallyChandler Carruth
cleans up all the chains allocated during the processing of each function so that for very large inputs we don't just grow memory usage without bound. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144533 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-14Remove an over-eager assert that was firing on one of the ARM regressionChandler Carruth
tests when I forcibly enabled block placement. It is apparantly possible for an unanalyzable block to fallthrough to a non-loop block. I don't actually beleive this is correct, I believe that 'canFallThrough' is returning true needlessly for the code construct, and I've left a bit of a FIXME on the verification code to try to track down why this is coming up. Anyways, removing the assert doesn't degrade the correctness of the algorithm. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144532 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-14Begin chipping away at one of the biggest quadratic-ish behaviors inChandler Carruth
this pass. We're leaving already merged blocks on the worklist, and scanning them again and again only to determine each time through that indeed they aren't viable. We can instead remove them once we're going to have to scan the worklist. This is the easy way to implement removing them. If this remains on the profile (as I somewhat suspect it will), we can get a lot more clever here, as the worklist's order is essentially irrelevant. We can use swapping and fold the two loops to reduce overhead even when there are many blocks on the worklist but only a few of them are removed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144531 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-14Under the hood, MBPI is doing a linear scan of every successor everyChandler Carruth
time it is queried to compute the probability of a single successor. This makes computing the probability of every successor of a block in sequence... really really slow. ;] This switches to a linear walk of the successors rather than a quadratic one. One of several quadratic behaviors slowing this pass down. I'm not really thrilled with moving the sum code into the public interface of MBPI, but I don't (at the moment) have ideas for a better interface. My direction I'm thinking in for a better interface is to have MBPI actually retain much more state and make *all* of these queries cheap. That's a lot of work, and would require invasive changes. Until then, this seems like the least bad (ie, least quadratic) solution. Suggestions welcome. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144530 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-14Reuse the logic in getEdgeProbability within getHotSucc in order toChandler Carruth
correctly handle blocks whose successor weights sum to more than UINT32_MAX. This is slightly less efficient, but the entire thing is already linear on the number of successors. Calling it within any hot routine is a mistake, and indeed no one is calling it. It also simplifies the code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144527 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-14Fix an overflow bug in MachineBranchProbabilityInfo. This pass relied onChandler Carruth
the sum of the edge weights not overflowing uint32, and crashed when they did. This is generally safe as BranchProbabilityInfo tries to provide this guarantee. However, the CFG can get modified during codegen in a way that grows the *sum* of the edge weights. This doesn't seem unreasonable (imagine just adding more blocks all with the default weight of 16), but it is hard to come up with a case that actually triggers 32-bit overflow. Fortuately, the single-source GCC build is good at this. The solution isn't very pretty, but its no worse than the previous code. We're already summing all of the edge weights on each query, we can sum them, check for an overflow, compute a scale, and sum them again. I've included a *greatly* reduced test case out of the GCC source that triggers it. It's a pretty lame test, as it clearly is just barely triggering the overflow. I'd like to have something that is much more definitive, but I don't understand the fundamental pattern that triggers an explosion in the edge weight sums. The buggy code is duplicated within this file. I'll colapse them into a single implementation in a subsequent commit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144526 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-14Use getVNInfoBefore() when it makes sense.Jakob Stoklund Olesen
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144517 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-14Teach machine block placement to cope with unnatural loops. These don'tChandler Carruth
get loop info structures associated with them, and so we need some way to make forward progress selecting and placing basic blocks. The technique used here is pretty brutal -- it just scans the list of blocks looking for the first unplaced candidate. It keeps placing blocks like this until the CFG becomes tractable. The cost is somewhat unfortunate, it requires allocating a vector of all basic block pointers eagerly. I have some ideas about how to simplify and optimize this, but I'm trying to get the logic correct first. Thanks to Benjamin Kramer for the reduced test case out of GCC. Sadly there are other bugs that GCC is tickling that I'm reducing and working on now. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144516 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Use kill slots instead of the previous slot in shrinkToUses.Jakob Stoklund Olesen
It's more natural to use the actual end points. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144515 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Cleanup some 80-columns violations and poor formatting. These snuck byChandler Carruth
when I was reading through the code for style. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144513 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Terminate all dead defs at the dead slot instead of the 'next' slot.Jakob Stoklund Olesen
This makes no difference for normal defs, but early clobber dead defs now look like: [Slot_EarlyClobber; Slot_Dead) instead of: [Slot_EarlyClobber; Slot_Register). Live ranges for normal dead defs look like: [Slot_Register; Slot_Dead) as before. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144512 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Simplify early clobber slots a bit.Jakob Stoklund Olesen
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144507 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Enhance the assertion mechanisms in place to make it easier to catchChandler Carruth
when we fail to place all the blocks of a loop. Currently this is happening for unnatural loops, and this logic helps more immediately point to the problem. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144504 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Rename SlotIndexes to match how they are used.Jakob Stoklund Olesen
The old naming scheme (load/use/def/store) can be traced back to an old linear scan article, but the names don't match how slots are actually used. The load and store slots are not needed after the deferred spill code insertion framework was deleted. The use and def slots don't make any sense because we are using half-open intervals as is customary in C code, but the names suggest closed intervals. In reality, these slots were used to distinguish early-clobber defs from normal defs. The new naming scheme also has 4 slots, but the names match how the slots are really used. This is a purely mechanical renaming, but some of the code makes a lot more sense now. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144503 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Teach MBP to force-merge layout successors for blocks with unanalyzableChandler Carruth
branches that also may involve fallthrough. In the case of blocks with no fallthrough, we can still re-order the blocks profitably. For example instruction decoding will in some cases continue past an indirect jump, making laying out its most likely successor there profitable. Note, no test case. I don't know how to write a test case that exercises this logic, but it matches the described desired semantics in discussions with Jakob and others. If anyone has a nice example of IR that will trigger this, that would be lovely. Also note, there are still assertion failures in real world code with this. I'm digging into those next, now that I know this isn't the cause. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144499 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Hoist another gross nested loop into a helper method.Chandler Carruth
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144498 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Add a missing doxygen comment for a helper method.Chandler Carruth
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144497 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Hoist a nested loop into its own method.Chandler Carruth
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144496 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Rewrite #3 of machine block placement. This is based somewhat on theChandler Carruth
second algorithm, but only loosely. It is more heavily based on the last discussion I had with Andy. It continues to walk from the inner-most loop outward, but there is a key difference. With this algorithm we ensure that as we visit each loop, the entire loop is merged into a single chain. At the end, the entire function is treated as a "loop", and merged into a single chain. This chain forms the desired sequence of blocks within the function. Switching to a single algorithm removes my biggest problem with the previous approaches -- they had different behavior depending on which system triggered the layout. Now there is exactly one algorithm and one basis for the decision making. The other key difference is how the chain is formed. This is based heavily on the idea Andy mentioned of keeping a worklist of blocks that are viable layout successors based on the CFG. Having this set allows us to consistently select the best layout successor for each block. It is expensive though. The code here remains very rough. There is a lot that needs to be done to clean up the code, and to make the runtime cost of this pass much lower. Very much WIP, but this was a giant chunk of code and I'd rather folks see it sooner than later. Everything remains behind a flag of course. I've added a couple of tests to exercise the issues that this iteration was motivated by: loop structure preservation. I've also fixed one test that was exhibiting the broken behavior of the previous version. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144495 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Prune more RALinScan. RALinScan was also here!NAKAMURA Takumi
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144487 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13More dead code elimination in VirtRegMap.Jakob Stoklund Olesen
This thing is looking a lot like a virtual register map now. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144486 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Stop tracking spill slot uses in VirtRegMap.Jakob Stoklund Olesen
Nobody cared, StackSlotColoring scans the instructions to find used stack slots. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144485 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Remove dead code and data from VirtRegMap.Jakob Stoklund Olesen
Most of this stuff was supporting the old deferred spill code insertion mechanism. Modern spillers just edit machine code in place. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144484 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Stop tracking unused registers in VirtRegMap.Jakob Stoklund Olesen
The information was only used by the register allocator in StackSlotColoring. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144482 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Remove the -color-ss-with-regs option.Jakob Stoklund Olesen
It was off by default. The new register allocators don't have the problems that made it necessary to reallocate registers during stack slot coloring. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144481 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Delete VirtRegRewriter.Jakob Stoklund Olesen
And there was much rejoicing. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144480 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-13Switch PBQP to VRM's trivial rewriter.Jakob Stoklund Olesen
The very complicated VirtRegRewriter is going away. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144479 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-12Delete the old spilling framework from LiveIntervalAnalysis.Jakob Stoklund Olesen
This is dead code, all register allocators use InlineSpiller. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144478 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3-18-g5258 (git 2.32.0) at 2025-07-16 07:27:52 +0000