summaryrefslogtreecommitdiffstats
path: root/llvm
Commit message (Collapse)AuthorAgeFilesLines
...
* IAS: correct debug line info for asm macrosSaleem Abdulrasool2014-12-242-4/+28
| | | | | | | | | | | | | | | | | Correct the line information generation for preprocessed assembly. Although we tracked the source information for the macro instantiation, we failed to account for the fact that we were instantiating a macro, which is populated into a new buffer and that the line information would be relative to the definition rather than the actual instantiation location. This could cause the line number associated with the statement to be very high due to wrapping of the difference calculated for the preprocessor line information emitted into the stream. Properly calculate the line for the macro instantiation, referencing the line where the macro is actually used as GCC/gas do. The test case uses x86, though the same problem exists on any other target using the LLVM IAS. llvm-svn: 224810
* [X86] Remove the single AdSize indicator and replace it with separate ↵Craig Topper2014-12-248-98/+119
| | | | | | | | AdSize16/32/64 flags. This removes a hardcoded list of instructions in the CodeEmitter. Eventually I intend to remove the predicates on the affected instructions since in any given mode two of them are valid if we supported addr32/addr16 prefixes in the assembler. llvm-svn: 224809
* MC: Don't emit .no_dead_strip on targets which don't support itDavid Majnemer2014-12-242-2/+8
| | | | llvm-svn: 224808
* LiveInterval: Remove accidentally committed debug code.Matthias Braun2014-12-241-10/+0
| | | | llvm-svn: 224807
* LiveInterval: Introduce createMainRangeFromSubranges().Matthias Braun2014-12-243-7/+234
| | | | | | | | | | | | | | | | | | | | This function constructs the main liverange by merging all subranges if subregister liveness tracking is available. This should be slightly faster to compute instead of performing the liveness calculation again for the main range. More importantly it avoids cases where the main liverange would cover positions where no subrange was live. These cases happened for partial definitions where the actual defined part was dead and only the undefined parts used later. The register coalescing requires that every part covered by the main live range has at least one subrange live. I also expect this function to become usefull later for places where the subranges are modified in a way that it is hard to correctly fix the main liverange in the machine scheduler, we can simply reconstruct it from subranges then. llvm-svn: 224806
* RegisterCoalescer: With subrange liveness there may be no RedefVNI for ↵Matthias Braun2014-12-241-3/+6
| | | | | | unused lanes. llvm-svn: 224805
* LiveRangeEdit: Check for completely empy subranges after removing ValNos.Matthias Braun2014-12-241-0/+1
| | | | | | | Completely empty subranges are not allowed and must be removed when subreg liveness is enabled. llvm-svn: 224804
* LiveIntervalAnalysis: Fix performance bug that I introduced in r224663.Matthias Braun2014-12-241-2/+2
| | | | | | | | Without a reference the code did not remember when moving the iterators of the subranges/registerunit ranges forward and instead would scan from the beginning again at the next position. llvm-svn: 224803
* [OCaml] PR21901: Update tests.Peter Zotov2014-12-241-2/+2
| | | | | | This finishes the fix partially applied by r224782. llvm-svn: 224802
* [OCaml] Expose Llvm_executionengine.get_{global_value,function}_address.Peter Zotov2014-12-244-17/+49
| | | | | | | | | Patch by Ramkumar Ramachandra <artagnon@gmail.com>. Also remove Llvm_executionengine.get_pointer_to_global, as it is actually deprecated and didn't appear in a stable release. llvm-svn: 224801
* [SROA] Update the documentation and names for accessing the slicesChandler Carruth2014-12-241-29/+36
| | | | | | | | | | | | | | | | | | | | | within a partition of an alloca in SROA. This reflects the fact that the organization of the slices isn't really ideal for analysis, but is the naive way in which the slices are available while we're processing them in the core partitioning algorithm. It is possible we could improve matters, and I've left a FIXME with one of my ideas for how to do this, but it is a lot of work, the benefit is somewhat minor, and it isn't clear that it would be strictly better. =/ Not really satisfying, but I'm out of really good ideas. This also improves one place where the debug logging failed to mark some split partitions. Now we log in one place, slightly later, and with accurate information about whether the slice is split by the partition being rewritten. llvm-svn: 224800
* Debug Info: In symmetry to DW_TAG_pointer_type, do not emit the byte sizeAdrian Prantl2014-12-242-1/+46
| | | | | | | of a DW_TAG_ptr_to_member_type. This restores the behavior from before r224780-r224781. llvm-svn: 224799
* [SROA] Refactor the integer and vector promotion testing logic toChandler Carruth2014-12-241-47/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | operate in terms of the new Partition class, and generally have a more clear set of arguments. No functionality changed. The most notable improvements here are consistently using the terminology of 'partition' for a collection of slices that will be rewritten together and 'slice' for a region of an alloca that is used by a particular instruction. This also makes it more clear that the split things are actually slices as well, just ones that will be split by the proposed partition. This doesn't yet address the confusing aspects of the partition's interface where slices that will be split by the partition and start prior to the partition are accesssed via Partition::splitSlices() while the core range of slices exposed by a Partition includes both unsplit slices and slices which will be split by the end, but started within the offset range of the partition. This is particularly hard to address because the algorithm which computes partitions quite literally doesn't know which slices these will end up being until too late. I'm looking at whether I can fix that or not, but I'm not optimistic. I'll update the comments and/or names to further explain this either way. I've also added one FIXME in this patch relating to this confusion so that I don't forget about it. llvm-svn: 224798
* [Hexagon] Removing old classes.Colin LeMahieu2014-12-241-80/+0
| | | | llvm-svn: 224795
* Another attempt to fix the LLVM Windows build bot lld-x86_64-win7, one last ↵Kevin Enderby2014-12-242-18/+18
| | | | | | place to fix I think. llvm-svn: 224794
* Attempt to fix the LLVM Windows build bot lld-x86_64-win7.Kevin Enderby2014-12-232-10/+10
| | | | llvm-svn: 224793
* Add printing the LC_THREAD load commands with llvm-objdump’s -private-headers.Kevin Enderby2014-12-236-0/+636
| | | | llvm-svn: 224792
* [asan] change the coverage collection scheme so that we can easily emit ↵Kostya Serebryany2014-12-234-21/+33
| | | | | | coverage for the entire process as a single bit set, and if coverage_bitset=1 actually emit that bitset llvm-svn: 224789
* [PowerPC] Ensure that the TOC reload directly follows bctrl on PPC64Hal Finkel2014-12-236-14/+88
| | | | | | | | | | | | | | | | On non-Darwin PPC64, the TOC reload needs to come directly after the bctrl instruction (for indirect calls) because the 'bctrl/ld 2, 40(1)' instruction sequence is interpreted by the unwinding code in libgcc. To make sure these occur as a pair, as with other pairings interpreted by the linker, fuse the two instructions into one instruction (for code generation only). In the future, we might wish to do this by emitting CFI directives instead, but this solution is simpler, and mirrors what GCC does. Additional discussion on this point is contained in the PR. Fixes PR22015. llvm-svn: 224788
* [Hexagon] Adding doubleword load.Colin LeMahieu2014-12-235-29/+27
| | | | llvm-svn: 224787
* [Hexagon] Reapplying 224775 load words.Colin LeMahieu2014-12-239-48/+53
| | | | llvm-svn: 224786
* [mips][microMIPS] Implement CACHE, PREF, SSNOP, EHB and PAUSE instructionsJozef Kolek2014-12-239-7/+122
| | | | | | Differential Revision: http://reviews.llvm.org/D5204 llvm-svn: 224785
* Reverting 224775 until mayLoad flag is addressed.Colin LeMahieu2014-12-238-52/+48
| | | | llvm-svn: 224783
* Finish removing DestroySource.Rafael Espindola2014-12-237-37/+10
| | | | | | Fixes pr21901. llvm-svn: 224782
* DIBuilder: Similar to createPointerType, make createMemberPointerType takeAdrian Prantl2014-12-232-5/+10
| | | | | | | | | a size and alignment. Several assertions in DwarfDebug rely on all variable types to report back a size, or to be derived from a type with a size. Tested in CFE. llvm-svn: 224780
* Always assert in DAGCombine and not only when -debug is enabledMehdi Amini2014-12-231-5/+6
| | | | | | | | | Right now in DAG Combine check the validity of the returned type only when -debug is given on the command line. However usually the test cases in the validation does not use -debug. An Assert build should always check this. llvm-svn: 224779
* Pass LSAN_OPTIONS down so that it is possible to add suppressions.Rafael Espindola2014-12-231-1/+2
| | | | llvm-svn: 224777
* Fix a leak found by asan.Rafael Espindola2014-12-231-5/+12
| | | | llvm-svn: 224776
* [Hexagon] Adding word loads.Colin LeMahieu2014-12-238-48/+52
| | | | llvm-svn: 224775
* [Hexagon] Adding signed halfword loads.Colin LeMahieu2014-12-236-30/+34
| | | | llvm-svn: 224774
* Fix a leak found by asan.Rafael Espindola2014-12-231-2/+3
| | | | llvm-svn: 224773
* [Hexagon] Adding unsigned halfword load.Colin LeMahieu2014-12-235-20/+18
| | | | llvm-svn: 224772
* [mips][microMIPS] Implement LWSP and SWSP instructionsJozef Kolek2014-12-2310-0/+126
| | | | | | Differential Revision: http://reviews.llvm.org/D6416 llvm-svn: 224771
* [OCaml] PR22014: OCaml bindings didn't link to libLLVM-*.so with -Wl,--as-neededPeter Zotov2014-12-231-2/+2
| | | | | | Patch by Evangelos Foutras <evangelos@foutrelis.com>. llvm-svn: 224766
* [ValueTracking] Move GlobalAlias handling to be after the max depth check in ↵Michael Kuperstein2014-12-232-15/+38
| | | | | | | | | | | | computeKnownBits() GlobalAlias handling used to be after GlobalValue handling, which meant it was, in practice, dead code. r220165 moved GlobalAlias handling to be before GlobalValue handling, but also moved it to be before the max depth check, causing an assert due to a recursion depth limit violation. This moves GlobalAlias handling forward to where it's safe, and changes the GlobalValue handling to only look at GlobalObjects. Differential Revision: http://reviews.llvm.org/D6758 llvm-svn: 224765
* AVX-512: Added FMA instructions, intrinsics an tests for KNL and SKX targetsElena Demikhovsky2014-12-236-81/+677
| | | | | | | | by Asaf Badouh http://reviews.llvm.org/D6456 llvm-svn: 224764
* [PowerPC] Don't mark the return-address slot as immutableHal Finkel2014-12-232-1/+26
| | | | | | | | | | | | | It is tempting to mark the fixed stack slot used to store the return address as immutable when lowering @llvm.returnaddress(i32 0). Unfortunately, within the function, it is not completely immutable: it is written during the function prologue. When using post-RA instruction scheduling, the prologue instructions are available for scheduling, and we're not free to interchange the order of a particular store in the prologue with loads from that stack location. Fixes PR21976. llvm-svn: 224761
* AVX-512: BLENDM - fixed encoding of the broadcast versionElena Demikhovsky2014-12-235-3/+348
| | | | | | Added more intrinsics and encoding tests. llvm-svn: 224760
* [DagCombine] Improve DAGCombiner BUILD_VECTOR when it has two sources of ↵Michael Kuperstein2014-12-232-12/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | elements This partially fixes PR21943. For AVX, we go from: vmovq (%rsi), %xmm0 vmovq (%rdi), %xmm1 vpermilps $-27, %xmm1, %xmm2 ## xmm2 = xmm1[1,1,2,3] vinsertps $16, %xmm2, %xmm1, %xmm1 ## xmm1 = xmm1[0],xmm2[0],xmm1[2,3] vinsertps $32, %xmm0, %xmm1, %xmm1 ## xmm1 = xmm1[0,1],xmm0[0],xmm1[3] vpermilps $-27, %xmm0, %xmm0 ## xmm0 = xmm0[1,1,2,3] vinsertps $48, %xmm0, %xmm1, %xmm0 ## xmm0 = xmm1[0,1,2],xmm0[0] To the expected: vmovq (%rdi), %xmm0 vmovhpd (%rsi), %xmm0, %xmm0 retq Fixing this for AVX2 is still open. Differential Revision: http://reviews.llvm.org/D6749 llvm-svn: 224759
* [PowerPC] Don't attempt a 64-bit pow2 division on PPC32Hal Finkel2014-12-232-0/+11
| | | | | | | | | | In r224033, in moving the signed power-of-2 division expansion into BuildSDIVPow2, I accidentally made it possible to attempt the lowering for a 64-bit division on PPC32. This later asserts. Fixes PR21928. llvm-svn: 224758
* [SimplifyCFG] Revise common code sinkingMichael Liao2014-12-232-32/+62
| | | | | | | | | | - Fix the case where more than 1 common instructions derived from the same operand cannot be sunk. When a pair of value has more than 1 derived values in both branches, only 1 derived value could be sunk. - Replace BB1 -> (BB2, PN) map with joint value map, i.e. map of (BB1, BB2) -> PN, which is more accurate to track common ops. llvm-svn: 224757
* Remove a bad cast in CloneModule()Michael Kuperstein2014-12-231-1/+1
| | | | | | A cast that was introduced in r209007 was accidentally left in after the changes made to GlobalAlias rules in r210062. This crashes if the aliasee is a now-leggal ConstantExpr. llvm-svn: 224756
* [ARM] Don't break alignment when combining base updates into load/stores.Ahmed Bougacha2014-12-234-26/+152
| | | | | | | | | | | | | | | | | | r223862/r224203 tried to also combine base-updating load/stores. There was a mistake there: the alignment was added as is as an operand to the ARMISD::VLD/VST node. However, the VLD/VST selection logic doesn't care about less-than-standard alignment attributes. For example, no matter the alignment of a v2i64 load (say 1), SelectVLD picks VLD1q64 (because of the memory type). But VLD1q64 ("vld1.64 {dXX, dYY}") is 8-aligned, per ARMARMv7a 3.2.1. For the 1-aligned load, what we really want is VLD1q8. This commit introduces bitcasts if necessary, and changes the vld/vst type to one whose standard alignment matches the original load/store alignment. Differential Revision: http://reviews.llvm.org/D6759 llvm-svn: 224754
* Fix UBSan bootstrap: replace shift of negative value with multiplication.Alexey Samsonov2014-12-231-1/+1
| | | | llvm-svn: 224752
* Fix UBSan bootstrap: don't bind reference to nullptr.Alexey Samsonov2014-12-231-2/+4
| | | | llvm-svn: 224751
* Revert r224739: Debug info: Teach SROA how to update debug info forChandler Carruth2014-12-234-233/+5
| | | | | | | | | | | fragmented variables. This caused codegen to start crashing when we built somewhat large programs with debug info and optimizations. 'check-msan' hit in, and I suspect a bootstrap would as well. I mailed a test case to the review thread. llvm-svn: 224750
* X86: Don't over-align combined loads.Jim Grosbach2014-12-232-8/+38
| | | | | | | | | | | When combining consecutive loads+inserts into a single vector load, we should keep the alignment of the base load. Doing otherwise can, and does, lead to using overly aligned instructions. In the included test case, for example, using a 32-byte vmovaps on a 16-byte aligned value. Oops. rdar://19190968 llvm-svn: 224746
* Make musttail more robust for vector types on x86Reid Kleckner2014-12-226-100/+302
| | | | | | | | | | | | | | | | Previously I tried to plug musttail into the existing vararg lowering code. That turned out to be a mistake, because non-vararg calls use significantly different register lowering, even on x86. For example, AVX vectors are usually passed in registers to normal functions and memory to vararg functions. Now musttail uses a completely separate lowering. Hopefully this can be used as the basis for non-x86 perfect forwarding. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D6156 llvm-svn: 224745
* Remove dynamic allocation/indirection from GCOVBlocks owned by GCOVFunctionDavid Blaikie2014-12-221-22/+25
| | | | | | | | | Since these are all created in the DenseMap before they are referenced, there's no problem with pointer validity by the time it's required. This removes another use of DeleteContainerSeconds/manual memory management which I'm cleaning up from time to time. llvm-svn: 224744
* Thumb1 frame lowering: Mark CFI instructions with the FrameSetup flag.Adrian Prantl2014-12-222-8/+16
| | | | | | | | | | | | | Followup to r224294: ARM/AArch64: Attach the FrameSetup MIFlag to CFI instructions. Debug info marks the first instruction without the FrameSetup flag as being the end of the function prologue. Any CFI instructions in the middle of the function prologue would cause debug info to end the prologue too early and worse, attach the line number of the CFI instruction, which incidentally is often 0. llvm-svn: 224743
OpenPOWER on IntegriCloud