summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* Turn off .debug_pubnames/pubtypes for PS4.Paul Robinson2015-03-051-2/+2
| | | | | | Differential Revision: http://reviews.llvm.org/D8067 llvm-svn: 231322
* Teach DIEInteger to emit FORM_strp and FORM_ref_addr attributes.Frederic Riss2015-03-041-0/+10
| | | | | | | | To be used/tested by llvm-dsymutil. (llvm-dsymutil does a 'static' link, no need for relocations for most things, so it'll just emit raw integers for most attributes) llvm-svn: 231298
* Support standard DWARF TLS opcode; Darwin and PS4 use it.Paul Robinson2015-03-043-2/+17
| | | | | | Differential Revision: http://reviews.llvm.org/D8018 llvm-svn: 231286
* Make DataLayout Non-Optional in the ModuleMehdi Amini2015-03-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: DataLayout keeps the string used for its creation. As a side effect it is no longer needed in the Module. This is "almost" NFC, the string is no longer canonicalized, you can't rely on two "equals" DataLayout having the same string returned by getStringRepresentation(). Get rid of DataLayoutPass: the DataLayout is in the Module The DataLayout is "per-module", let's enforce this by not duplicating it more than necessary. One more step toward non-optionality of the DataLayout in the module. Make DataLayout Non-Optional in the Module Module->getDataLayout() will never returns nullptr anymore. Reviewers: echristo Subscribers: resistor, llvm-commits, jholewinski Differential Revision: http://reviews.llvm.org/D7992 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231270
* Revert the test commit.Wei Mi2015-03-041-1/+0
| | | | llvm-svn: 231264
* Test commit. It will be reverted in the next commit.Wei Mi2015-03-041-0/+1
| | | | llvm-svn: 231262
* Fix DwarfExpression::AddMachineRegExpression so it doesn't read past theAdrian Prantl2015-03-041-11/+15
| | | | | | | end of an expression that ends with DW_OP_plus. Caught by the ASAN build bots. llvm-svn: 231260
* Mutate TargetLowering::shouldExpandAtomicRMWInIR to specifically dictate how ↵JF Bastien2015-03-041-9/+24
| | | | | | | | | | | | | | | | | | | | | AtomicRMWInsts are expanded. Summary: In PNaCl, most atomic instructions have their own @llvm.nacl.atomic.* function, each one, with a few exceptions, represents a consistent behaviour across all NaCl-supported targets. Unfortunately, the atomic RMW operations nand, [u]min, and [u]max aren't directly represented by any such @llvm.nacl.atomic.* function. This patch refines shouldExpandAtomicRMWInIR in TargetLowering so that a future `Le32TargetLowering` class can selectively inform the caller how the target desires the atomic RMW instruction to be expanded (ie via load-linked/store-conditional for ARM/AArch64, via cmpxchg for X86/others?, or not at all for Mips) if at all. This does not represent a behavioural change and as such no tests were added. Patch by: Richard Diamond. Reviewers: jfb Reviewed By: jfb Subscribers: jfb, aemerson, t.p.northover, llvm-commits Differential Revision: http://reviews.llvm.org/D7713 llvm-svn: 231250
* [MBP] Fix a really horrible bug in MachineBlockPlacement, but behindChandler Carruth2015-03-041-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a flag for now. First off, thanks to Daniel Jasper for really pointing out the issue here. It's been here forever (at least, I think it was there when I first wrote this code) without getting really noticed or fixed. The key problem is what happens when two reasonably common patterns happen at the same time: we outline multiple cold regions of code, and those regions in turn have diamonds or other CFGs for which we can't just topologically lay them out. Consider some C code that looks like: if (a1()) { if (b1()) c1(); else d1(); f1(); } if (a2()) { if (b2()) c2(); else d2(); f2(); } done(); Now consider the case where a1() and a2() are unlikely to be true. In that case, we might lay out the first part of the function like: a1, a2, done; And then we will be out of successors in which to build the chain. We go to find the best block to continue the chain with, which is perfectly reasonable here, and find "b1" let's say. Laying out successors gets us to: a1, a2, done; b1, c1; At this point, we will refuse to lay out the successor to c1 (f1) because there are still un-placed predecessors of f1 and we want to try to preserve the CFG structure. So we go get the next best block, d1. ... wait for it ... Except that the next best block *isn't* d1. It is b2! d1 is waaay down inside these conditionals. It is much less important than b2. Except that this is exactly what we didn't want. If we keep going we get the entire set of the rest of the CFG *interleaved*!!! a1, a2, done; b1, c1; b2, c2; d1, f1; d2, f2; So we clearly need a better strategy here. =] My current favorite strategy is to actually try to place the block whose predecessor is closest. This very simply ensures that we unwind these kinds of CFGs the way that is natural and fitting, and should minimize the number of cache lines instructions are spread across. It also happens to be *dead simple*. It's like the datastructure was specifically set up for this use case or something. We only push blocks onto the work list when the last predecessor for them is placed into the chain. So the back of the worklist *is* the nearest next block. Unfortunately, a change like this is going to cause *soooo* many benchmarks to swing wildly. So for now I'm adding this under a flag so that we and others can validate that this is fixing the problems described, that it seems possible to enable, and hopefully that it fixes more of our problems long term. llvm-svn: 231238
* Add a flag to experiment with outlining optional branches.Daniel Jasper2015-03-041-2/+46
| | | | | | | | | | | | | In a CFG with the edges A->B->C and A->C, B is an optional branch. LLVM's default behavior is to lay the blocks out naturally, i.e. A, B, C, in order to improve code locality and fallthroughs. However, if a function contains many of those optional branches only a few of which are taken, this leads to a lot of unnecessary icache misses. Moving B out of line can work around this. Review: http://reviews.llvm.org/D7719 llvm-svn: 231230
* [DAGCombine] Fix a bug in a BUILD_VECTOR combineMichael Kuperstein2015-03-041-2/+3
| | | | | | | | | | When trying to convert a BUILD_VECTOR into a shuffle, we try to split a single source vector that is twice as wide as the destination vector. We can not do this when we also need the zero vector to create a blend. This fixes PR22774. Differential Revision: http://reviews.llvm.org/D8040 llvm-svn: 231219
* Move emitDIE and emitAbbrevs to AsmPrinter. NFC.Frederic Riss2015-03-045-68/+66
| | | | | | | | | | | | | | (They are called emitDwarfDIE and emitDwarfAbbrevs in their new home) llvm-dsymutil wants to reuse that code, but it doesn't have a DwarfUnit or a DwarfDebug object to call those. It has access to an AsmPrinter though. Having emitDIE in the AsmPrinter also removes the DwarfFile dependency on DwarfDebug, and thus the patch drops that field. Differential Revision: http://reviews.llvm.org/D8024 llvm-svn: 231210
* Constify AsmPrinter passed to DIE methods.Frederic Riss2015-03-041-22/+22
| | | | llvm-svn: 231209
* Use report_fatal_error instead of unreachable for -fast-isel-abortMehdi Amini2015-03-041-3/+3
| | | | | | | Suggestion by Andrea Di Biagio From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231201
* Use the vanilla func_end symbol for .size.Rafael Espindola2015-03-041-7/+4
| | | | | | No need to create yet another temp symbol. llvm-svn: 231198
* Recommit r231168: unique_ptrify LiveRange::segmentSetDavid Blaikie2015-03-042-3/+4
| | | | | | | | | | | | | | | | | | | | | | | GCC 4.7's libstdc++ doesn't have std::map::emplace, but it does have std::unordered_map::emplace, and the use case here doesn't appear to need ordering. The container has been changed in a separate/precursor patch, and now this patch should hopefully build cleanly even with GCC 4.7. & then I realized the order of the container did matter, so extra handling of ordering was added in r231189. Original commit message: This makes LiveRange non-copyable, and LiveInterval is already non-movable (due to the explicit dtor), so now it's non-copyable and non-movable. Fix the one case where we were relying on the (deprecated in C++11) implicit copy ctor of LiveInterval (which happened to work because the ctor created an object with a null segmentSet, so double-deleting the null pointer was fine). llvm-svn: 231192
* Recommit r231175: Change LiveStackAnalysis::SS2IntervalMap from std::map to ↵David Blaikie2015-03-041-2/+10
| | | | | | | | | | | | | | | | std::unordered_map The order of this container was needed at one point - so, at that point create a temporary array of pointers, sort those, then iterate them. This keeps lookup efficient (& the lesser issue, of allowing the use of emplace... ), object identity preserved, and ordered iteration in the one place that requires it. While this has no functional change, I realize it does mean allocating an extra data structure and performing a sort - so if this looks suspect to anyone regarding perf characteristics, I'm all ears. llvm-svn: 231189
* RegisterCoalescer: Gracefully continue if subrange merging fails.Matthias Braun2015-03-041-18/+48
| | | | | | | | | | | There is a known bug where the register coalescer fails to merge subranges when multiple ranges end up in the "overflow" bit 32 of the lanemasks. A proper fix for this is complicated so for now this is a workaround which lets the register coalescer drop the subregister liveness information (we just loose some precision by that) and continue. llvm-svn: 231186
* Drop the "eh_" from eh_func_begin and eh_func_end.Rafael Espindola2015-03-041-2/+2
| | | | | | They will be used for more than eh tables. llvm-svn: 231185
* Revert "unique_ptrify LiveRange::segmentSet"David Blaikie2015-03-042-4/+3
| | | | | | | | Apparently something does care about ordering of LiveIntervals... so revert all that stuff (r231175, r231176, r231177) & take some time to re-evaluate. llvm-svn: 231184
* Recommit r231168: unique_ptrify LiveRange::segmentSetDavid Blaikie2015-03-032-3/+4
| | | | | | | | | | | | | | | | | | | | GCC 4.7's libstdc++ doesn't have std::map::emplace, but it does have std::unordered_map::emplace, and the use case here doesn't appear to need ordering. The container has been changed in a separate/precursor patch, and now this patch should hopefully build cleanly even with GCC 4.7. Original commit message: This makes LiveRange non-copyable, and LiveInterval is already non-movable (due to the explicit dtor), so now it's non-copyable and non-movable. Fix the one case where we were relying on the (deprecated in C++11) implicit copy ctor of LiveInterval (which happened to work because the ctor created an object with a null segmentSet, so double-deleting the null pointer was fine). llvm-svn: 231176
* Revert "unique_ptrify LiveRange::segmentSet"David Blaikie2015-03-032-4/+3
| | | | | | | | GCC 4.7 *shakes fist* (doesn't have std::map::emplace... ) This reverts commit r231168. llvm-svn: 231173
* unique_ptrify LiveRange::segmentSetDavid Blaikie2015-03-032-3/+4
| | | | | | | | | | | | | This makes LiveRange non-copyable, and LiveInterval is already non-movable (due to the explicit dtor), so now it's non-copyable and non-movable. Fix the one case where we were relying on the (deprecated in C++11) implicit copy ctor of LiveInterval (which happened to work because the ctor created an object with a null segmentSet, so double-deleting the null pointer was fine). llvm-svn: 231168
* WinEH: Remove vestigial EH objectReid Kleckner2015-03-031-43/+13
| | | | | | | | Ultimately, we'll need to leave something behind to indicate which alloca will hold the exception, but we can figure that out when it comes time to emit the __CxxFrameHandler3 catch handler table. llvm-svn: 231164
* Fix a problem where the TwoAddressInstructionPass which generate redundant ↵Eric Christopher2015-03-031-0/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | register moves in a loop. From: int M, total; void foo() { int i; for (i = 0; i < M; i++) { total = total + i / 2; } } This is the kernel loop: .LBB0_2: # %for.body =>This Inner Loop Header: Depth=1 movl %edx, %esi movl %ecx, %edx shrl $31, %edx addl %ecx, %edx sarl %edx addl %esi, %edx incl %ecx cmpl %eax, %ecx jl .LBB0_2 -------------------------- The first mov insn "movl %edx, %esi" could be removed if we change "addl %esi, %edx" to "addl %edx, %esi". The IR before TwoAddressInstructionPass is: BB#2: derived from LLVM BB %for.body Predecessors according to CFG: BB#1 BB#2 %vreg3<def> = COPY %vreg12<kill>; GR32:%vreg3,%vreg12 %vreg2<def> = COPY %vreg11<kill>; GR32:%vreg2,%vreg11 %vreg7<def,tied1> = SHR32ri %vreg3<tied0>, 31, %EFLAGS<imp-def,dead>; GR32:%vreg7,%vreg3 %vreg8<def,tied1> = ADD32rr %vreg3<tied0>, %vreg7<kill>, %EFLAGS<imp-def,dead>; GR32:%vreg8,%vreg3,%vreg7 %vreg9<def,tied1> = SAR32r1 %vreg8<kill,tied0>, %EFLAGS<imp-def,dead>; GR32:%vreg9,%vreg8 %vreg4<def,tied1> = ADD32rr %vreg9<kill,tied0>, %vreg2<kill>, %EFLAGS<imp-def,dead>; GR32:%vreg4,%vreg9,%vreg2 %vreg5<def,tied1> = INC64_32r %vreg3<kill,tied0>, %EFLAGS<imp-def,dead>; GR32:%vreg5,%vreg3 CMP32rr %vreg5, %vreg0, %EFLAGS<imp-def>; GR32:%vreg5,%vreg0 %vreg11<def> = COPY %vreg4; GR32:%vreg11,%vreg4 %vreg12<def> = COPY %vreg5<kill>; GR32:%vreg12,%vreg5 JL_4 <BB#2>, %EFLAGS<imp-use,kill> Now TwoAddressInstructionPass will choose vreg9 to be tied with vreg4. However, it doesn't see that there is copy from vreg4 to vreg11 and another copy from vreg11 to vreg2 inside the loop body. To remove those copies, it is necessary to choose vreg2 to be tied with vreg4 instead of vreg9. This code pattern commonly appears when there is reduction operation in a loop. So check for a reversed copy chain and if we encounter one then we can commute the add instruction so we can avoid a copy. Patch by Wei Mi. http://reviews.llvm.org/D7806 llvm-svn: 231148
* DAGCombiner::LoadedSlice: Remove explicit copy ctor in favor of the Rule of ZeroDavid Blaikie2015-03-031-3/+0
| | | | | | | This way, the copy assignment operator can be used without hitting the deprecated case in C++11. llvm-svn: 231144
* Revert "Remove the explicit SDNodeIterator::operator= in favor of the ↵David Blaikie2015-03-033-4/+6
| | | | | | | | | | | implicit default" Accidentally committed a few more of these cleanup changes than intended. Still breaking these out & tidying them up. This reverts commit r231135. llvm-svn: 231136
* Remove the explicit SDNodeIterator::operator= in favor of the implicit defaultDavid Blaikie2015-03-033-6/+4
| | | | | | | | | | There doesn't seem to be any need to assert that iterator assignment is between iterators over the same node - if you want to reuse an iterator variable to iterate another node, that's perfectly acceptable. Just don't mix comparisons between iterators into disjoint sequences, as usual. llvm-svn: 231135
* Remove LatencyPriorityQueue::dump because it relies on an implicit copy ctor ↵David Blaikie2015-03-031-13/+0
| | | | | | | | | | | | | which is deprecated in C++11 (due to the presence of a user-declare dtor in the base class) This type could be made copyable (= default a protected copy ctor in the base class, and preferably make the derived class final to avoid risks of providing a slicing copy operation to further derived classes) but it seemed easier to avoid that complexity for a dump function that I assume (by symmetry with ResourcePriorityQueue's dump, which was actively buggy) not often used. llvm-svn: 231133
* unique_ptrify ResourcePriorityQueue::ResourceModelDavid Blaikie2015-03-031-1/+1
| | | | llvm-svn: 231127
* Remove ResourcePriorityQueue::dump as it relies on copying a non-copyable ↵David Blaikie2015-03-031-14/+0
| | | | | | type which would result in a double-delete llvm-svn: 231126
* Fixing problem with field initialization orderAndrew Kaylor2015-03-031-2/+2
| | | | llvm-svn: 231122
* Fix PR22762. When emitting a DWARF expression check whether this is theAdrian Prantl2015-03-031-6/+7
| | | | | | | | frame register before checking if there is a DWARF register number for it. Thanks to H.J. Lu for diagnosing this and providing the testcase! llvm-svn: 231121
* Outline cleanup handlers for native Windows C++ exception handlingAndrew Kaylor2015-03-031-97/+251
| | | | | | Differential Revision: http://reviews.llvm.org/D7865 llvm-svn: 231117
* Add a comment above findRepresentativeClass explaining why it'sEric Christopher2015-03-031-0/+4
| | | | | | where it is so that future generations can understand. llvm-svn: 231111
* Fix PR22750: non-determinism causes assertion failure in DWARF generationDario Domizioli2015-03-031-2/+5
| | | | | | | | | | | | | | | | | | | | | | | The cause of the issue is the interaction of two factors: 1) When generating a DW_TAG_imported_declaration DIE which imports another imported declaration, the code in AsmPrinter/DwarfCompileUnit.cpp asserts that the second imported declaration must already have a DIE. 2) There is a non-determinism in the order in which imported declarations within the same scope are processed. Because of the non-determinism (2), it is possible that an imported declaration is processed before another one it depends on, breaking the assumption in (1). The source of the non-determinism is that the imported declaration DIDescriptors are sorted by scope in DwarfDebug::beginModule(); however that sort is not a stable_sort, therefore the order of the declarations within the same scope is not preserved. The attached patch changes the std::sort to a std::stable_sort and it fixes the problem. Test omitted due to it being non-deterministic and depending on the implementation of std::sort. llvm-svn: 231100
* During PHI elimination, split critical edges that move copies out of loops.Daniel Jasper2015-03-031-7/+13
| | | | | | | | | | | | | | | | | | | | This prevents the behavior observed in llvm.org/PR22369. I am not sure whether I am reading the code correctly, but the early exit based on isLiveOutPastPHIs() seems to make the wrong assumption that RegisterCoalescer won't be able to coalesce those copies later. This change hides the new behavior behind -no-phi-elim-live-out-early-exit as it currently breaks four tests: * Assertion in: CodeGen/Hexagon/hwloop-cleanup.ll * Worse code in: CodeGen/X86/coalescer-commute4.ll CodeGen/X86/phys_subreg_coalesce-2.ll CodeGen/X86/zlib-longest-match.ll The root cause here seems to be that the heuristic that determines the visitation order in RegisterCoalescer gets less lucky. llvm-svn: 231064
* Remap arguments and non-alloca values used by outlined C++ exception handlers.Andrew Kaylor2015-03-031-40/+76
| | | | | | Differential Revision: http://reviews.llvm.org/D7844 llvm-svn: 231042
* Revert "Revert "For the dwarf expression code get the subtarget off of the ↵Adrian Prantl2015-03-022-6/+8
| | | | | | | | current"" This reapplies r230990 without modifications. llvm-svn: 231024
* Refactor DebugLocDWARFExpression so it doesn't require access to theAdrian Prantl2015-03-028-137/+175
| | | | | | | | | | | | | | TargetRegisterInfo. DebugLocEntry now holds a buffer with the raw bytes of the pre-calculated DWARF expression. Ought to be NFC, but it does slightly alter the output format of the textual assembly. This reapplies 230930 without the assertion in DebugLocEntry::finalize() because not all Machine registers can be lowered into DWARF register numbers and floating point constants cannot be expressed. llvm-svn: 231023
* Use read{16,32,64}{le,be}() instead of ↵Rui Ueyama2015-03-022-4/+4
| | | | | | *reinterpret_cast<u{little,big}{16,32,64}_t>(). llvm-svn: 231016
* Revert "Refactor DebugLocDWARFExpression so it doesn't require access to the"Adrian Prantl2015-03-028-165/+125
| | | | | | This reverts commit 230975 to investigate buildbot breakage. llvm-svn: 231004
* Revert "For the dwarf expression code get the subtarget off of the current"Adrian Prantl2015-03-022-8/+6
| | | | | | This reverts commit 230990 because also reverting 230975. llvm-svn: 231003
* For the dwarf expression code get the subtarget off of the currentEric Christopher2015-03-022-6/+8
| | | | | | MachineFunction. llvm-svn: 230990
* Refactor DebugLocDWARFExpression so it doesn't require access to theAdrian Prantl2015-03-028-125/+165
| | | | | | | | | | | | | TargetRegisterInfo. DebugLocEntry now holds a buffer with the raw bytes of the pre-calculated DWARF expression. Ought to be NFC, but it does slightly alter the output format of the textual assembly. This reapplies 230930 with a relaxed assertion in DebugLocEntry::finalize() that allows for empty DWARF expressions for constant FP values. llvm-svn: 230975
* Accidentaly inverted the condition again. Sorry.Benjamin Kramer2015-03-021-1/+1
| | | | llvm-svn: 230973
* Avoid assertion in MSVC 2013 debug builds.Benjamin Kramer2015-03-021-1/+1
| | | | llvm-svn: 230972
* Simplify code. NFC.Benjamin Kramer2015-03-021-11/+3
| | | | llvm-svn: 230948
* Revert r230930, it caused PR22747.Nico Weber2015-03-028-164/+125
| | | | llvm-svn: 230932
* Refactor DebugLocDWARFExpression so it doesn't require access to theAdrian Prantl2015-03-028-125/+164
| | | | | | | | | | TargetRegisterInfo. DebugLocEntry now holds a buffer with the raw bytes of the pre-calculated DWARF expression. Ought to be NFC, but it does slightly alter the output format of the textual assembly. llvm-svn: 230930
OpenPOWER on IntegriCloud