summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [PowerPC] Remove unnecessary and incomplete commentaryBill Schmidt2015-03-041-412/+0
| | | | | | | | | | This "itinerary class map" in PPCSchedule.td is incomplete and redundant with the actual code. As it provides no value, we've decided to remove it. No functional change. llvm-svn: 231246
* [X86][FastISel] Simplify the logic in method X86SelectSIToFP.Andrea Di Biagio2015-03-041-21/+13
| | | | | | | | | | | | | | | | The target-independent selection algorithm in FastISel already knows how to select a SINT_TO_FP if the target is SSE but not AVX. On targets that have SSE but not AVX, the tablegen'd 'fastEmit' functions for ISD::SINT_TO_FP know how to select instruction X86::CVTSI2SSrr (for an i32 to f32 conversion) and X86::CVTSI2SDrr (for an i32 to f64 conversion). This patch simplifies the logic in method X86SelectSIToFP knowing that the code would not be reachable if the subtarget doesn't have AVX. No functional change intended. llvm-svn: 231243
* asan: do not instrument direct inbounds accesses to stack variablesDmitry Vyukov2015-03-041-263/+285
| | | | | | | | | | | | | | | Do not instrument direct accesses to stack variables that can be proven to be inbounds, e.g. accesses to fields of structs on stack. But it eliminates 33% of instrumentation on webrtc/modules_unittests (number of memory accesses goes down from 290152 to 193998) and reduces binary size by 15% (from 74M to 64M) and improved compilation time by 6-12%. The optimization is guarded by asan-opt-stack flag that is off by default. http://reviews.llvm.org/D7583 llvm-svn: 231241
* [mips] Rename the LA/LI/DLI TableGen definitions and classes. NFC.Toma Tabacu2015-03-043-16/+17
| | | | | | | | | | | | | | | | Summary: Use more reasonable names for these pseudo-instructions. As there's only one definition tied to any one of these classes, I named them with abbreviated versions of their respective class' name. Reviewers: dsanders Reviewed By: dsanders Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7831 llvm-svn: 231240
* [mips] Keep the parameter list of Filler::searchRange() consistent. NFC.Vasileios Kalintiris2015-03-041-9/+9
| | | | | | | | | | | | | | Summary: Move the "Filler" parameter to the end of the parameter list as it is, conceptually, the only output parameter of that function. Reviewers: dsanders Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7726 llvm-svn: 231239
* [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
* [mips] Specify the correct value type when combining a CMovFP node.Vasileios Kalintiris2015-03-041-4/+2
| | | | | | | | | This commit fixes a bug introduced in r230956 where we were creating CMovFP_{T,F} nodes with multiple return value types (one for each operand). With this change the return value type of the new node is the same as the value type of the True/False operands of the original node. llvm-svn: 231237
* 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
* Fix PR22408 - LLVM producing AArch64 TLS relocations that GNU linkers cannot ↵Kristof Beyls2015-03-047-132/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | handle yet. As is described at http://llvm.org/bugs/show_bug.cgi?id=22408, the GNU linkers ld.bfd and ld.gold currently only support a subset of the whole range of AArch64 ELF TLS relocations. Furthermore, they assume that some of the code sequences to access thread-local variables are produced in a very specific sequence. When the sequence is not as the linker expects, it can silently mis-relaxe/mis-optimize the instructions. Even if that wouldn't be the case, it's good to produce the exact sequence, as that ensures that linkers can perform optimizing relaxations. This patch: * implements support for 16MiB TLS area size instead of 4GiB TLS area size. Ideally clang would grow an -mtls-size option to allow support for both, but that's not part of this patch. * by default doesn't produce local dynamic access patterns, as even modern ld.bfd and ld.gold linkers do not support the associated relocations. An option (-aarch64-elf-ldtls-generation) is added to enable generation of local dynamic code sequence, but is off by default. * makes sure that the exact expected code sequence for local dynamic and general dynamic accesses is produced, by making use of a new pseudo instruction. The patch also removes two (AArch64ISD::TLSDESC_BLR, AArch64ISD::TLSDESC_CALL) pre-existing AArch64-specific pseudo SDNode instructions that are superseded by the new one (TLSDESC_CALLSEQ). llvm-svn: 231227
* [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
* [MC][Target] Implement support for R_X86_64_SIZE{32,64}.Davide Italiano2015-03-042-0/+8
| | | | | | | Differential Revision: D7990 Reviewed by: rafael, majnemer llvm-svn: 231216
* [llvm-pdbdump] Display full enum definitions.Zachary Turner2015-03-042-2/+14
| | | | | | | | | | | This will now display enum definitions both at the global scope as well as nested inside of classes. Additionally, it will no longer display enums at the global scope if the enum is nested. Instead, it will omit the definition of the enum globally and instead emit it in the corresponding class definition. llvm-svn: 231215
* 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
* Workaround MSVC not providing implicit move membersDavid Blaikie2015-03-041-0/+8
| | | | llvm-svn: 231204
* 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
* unique_ptrify ValID::ConstantStructEltsDavid Blaikie2015-03-042-11/+9
| | | | llvm-svn: 231200
* LLParser: Avoid copying ValIDs, the copy ctor is deprecated in C++11 due to ↵David Blaikie2015-03-041-1/+6
| | | | | | the presence of a user-declared dtor llvm-svn: 231199
* 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
* Remove MCStreamer include which isn't used here. NFCPete Cooper2015-03-041-1/+0
| | | | llvm-svn: 231195
* This file should always have included MCAssembler and not MCStreamer. NFCPete Cooper2015-03-041-1/+1
| | | | llvm-svn: 231194
* Remove MCStreamer.h include from MCContext.h and explictly include it where ↵Pete Cooper2015-03-046-0/+6
| | | | | | necessary. NFC llvm-svn: 231193
* 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
* [RewriteStatepointsForGC] Fix a relocation bug w.r.t values defined by ↵Philip Reames2015-03-041-2/+12
| | | | | | | | | | | | | | | invoke instructions RewriteStatepointsForGC pass emits an alloca for each GC pointer which will be relocated. It then inserts stores after def and all relocations, and inserts loads before each use as well. In the end, mem2reg is used to update IR with relocations in SSA form. However, there is a problem with inserting stores for values defined by invoke instructions. The code didn't expect a def was a terminator instruction, and inserting instructions after these terminators resulted in malformed IR. This patch fixes this problem by handling invoke instructions as a special case. If the def is an invoke instruction, the store will be inserted at the beginning of the normal destination block. Since return value from invoke instruction does not dominate the unwind destination block, no action is needed there. Patch by: Chen Li Differential Revision: http://reviews.llvm.org/D7923 llvm-svn: 231183
* Remove 'llvm.x86.avx2.vbroadcasti128' intrinsic.Juergen Ributzka2015-03-042-5/+12
| | | | | | | | | | | The intrinsic is no longer generated by the front-end. Remove the intrinsic and auto-upgrade it to a vector shuffle. Reviewed by Nadav This is related to rdar://problem/18742778. llvm-svn: 231182
* 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
* Move TargetLibraryInfo data from two files into one common .def file.Jan Wen Voung2015-03-031-330/+2
| | | | | | | | | | | | | | | Summary: This makes it more obvious that the enum definition and the "StandardName" array is in sync. Mechanically refactored w/ a python script. Test Plan: still compiles Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7845 llvm-svn: 231172
* 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
* [sanitizer/coverage] Add AFL-style coverage counters (search heuristic for ↵Kostya Serebryany2015-03-038-8/+98
| | | | | | | | | | | | | | | | | | | | | | | | | fuzzing). Introduce -mllvm -sanitizer-coverage-8bit-counters=1 which adds imprecise thread-unfriendly 8-bit coverage counters. The run-time library maps these 8-bit counters to 8-bit bitsets in the same way AFL (http://lcamtuf.coredump.cx/afl/technical_details.txt) does: counter values are divided into 8 ranges and based on the counter value one of the bits in the bitset is set. The AFL ranges are used here: 1, 2, 3, 4-7, 8-15, 16-31, 32-127, 128+. These counters provide a search heuristic for single-threaded coverage-guided fuzzers, we do not expect them to be useful for other purposes. Depending on the value of -fsanitize-coverage=[123] flag, these counters will be added to the function entry blocks (=1), every basic block (=2), or every edge (=3). Use these counters as an optional search heuristic in the Fuzzer library. Add a test where this heuristic is critical. llvm-svn: 231166
* Remove subtarget dependence in pass pipeline setup for AArch64.Eric Christopher2015-03-032-4/+6
| | | | llvm-svn: 231165
* 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
* InstCombine: Ensure select condition types are identical before mergingDavid Majnemer2015-03-031-28/+32
| | | | | | | | | | Selection conditions may be vectors or scalars. Make sure InstCombine doesn't indiscriminately assume that a select which is value dependent on another select have identical select condition types. This fixes PR22773. llvm-svn: 231156
* Avoid copying LiveInterval, this could lead to a double-deleteDavid Blaikie2015-03-031-1/+1
| | | | llvm-svn: 231154
* 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
* Remove getDataLayout() from Instruction/GlobalValue/BasicBlock/FunctionMehdi Amini2015-03-035-16/+12
| | | | | | | | | | | | | | | | | Summary: This does not conceptually belongs here. Instead provide a shortcut getModule() that provides access to the DataLayout. Reviewers: chandlerc, echristo Reviewed By: echristo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8027 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231147
* 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
* RewriteStatepointsForGC::PhiState: Remove explicit copy ctor in favor of the ↵David Blaikie2015-03-031-3/+0
| | | | | | | | | | | | Rule of Zero The assertion was just checking a class invariant that's pretty easy to verify by inspection (no mutating operations, and the two non-copy ctors already ensure the state is maintained) so remove the explicit copy ctor in favor of the default, thus allowing the use of the default copy assignment operator without hitting the C++11 deprecation here. llvm-svn: 231143
* Teach ComputeNumSignBits about signed divisions.Nadav Rotem2015-03-031-0/+17
| | | | | | | http://reviews.llvm.org/D8028 rdar://20023136 llvm-svn: 231140
* Revert "Remove the explicit SDNodeIterator::operator= in favor of the ↵David Blaikie2015-03-038-20/+22
| | | | | | | | | | | 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-038-22/+20
| | | | | | | | | | 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
* [X86][ELF] Correct relocation for DWARF TLS referencesPaul Robinson2015-03-033-11/+14
| | | | | | | | | Previously we had only Linux using DTPOFF for these; all X86 ELF targets should. Fixes a side issue mentioned in PR21077. Differential Revision: http://reviews.llvm.org/D8011 llvm-svn: 231130
* remove enum value names from comments; NFCSanjay Patel2015-03-031-70/+68
| | | | llvm-svn: 231129
* 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
OpenPOWER on IntegriCloud