summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* MC: address some comments in deprecation checksSaleem Abdulrasool2014-12-241-4/+4
| | | | | | | | | Bob Wilson pointed out the unnecessary checks that had been committed to the instruction check predicates. The check was meant to ensure that the check was not accidentally applied to non-ARM instructions. This is better served as an assertion rather than a condition check. llvm-svn: 224825
* MC: Label definitions are permitted after .set directivesDavid Majnemer2014-12-242-0/+7
| | | | | | | | | .set directives may be overridden by other .set directives as well as label definitions. This fixes PR22019. llvm-svn: 224811
* IAS: correct debug line info for asm macrosSaleem Abdulrasool2014-12-241-4/+8
| | | | | | | | | | | | | | | | | 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-245-93/+107
| | | | | | | | 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-241-1/+5
| | | | llvm-svn: 224808
* LiveInterval: Remove accidentally committed debug code.Matthias Braun2014-12-241-10/+0
| | | | llvm-svn: 224807
* LiveInterval: Introduce createMainRangeFromSubranges().Matthias Braun2014-12-242-7/+226
| | | | | | | | | | | | | | | | | | | | 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
* [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-241-1/+2
| | | | | | | 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
* Add printing the LC_THREAD load commands with llvm-objdump’s -private-headers.Kevin Enderby2014-12-231-0/+5
| | | | llvm-svn: 224792
* [asan] change the coverage collection scheme so that we can easily emit ↵Kostya Serebryany2014-12-231-12/+24
| | | | | | 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-235-13/+70
| | | | | | | | | | | | | | | | 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-234-29/+17
| | | | llvm-svn: 224787
* [Hexagon] Reapplying 224775 load words.Colin LeMahieu2014-12-237-46/+39
| | | | llvm-svn: 224786
* [mips][microMIPS] Implement CACHE, PREF, SSNOP, EHB and PAUSE instructionsJozef Kolek2014-12-235-7/+75
| | | | | | Differential Revision: http://reviews.llvm.org/D5204 llvm-svn: 224785
* Reverting 224775 until mayLoad flag is addressed.Colin LeMahieu2014-12-236-38/+46
| | | | llvm-svn: 224783
* Finish removing DestroySource.Rafael Espindola2014-12-231-1/+1
| | | | | | Fixes pr21901. llvm-svn: 224782
* DIBuilder: Similar to createPointerType, make createMemberPointerType takeAdrian Prantl2014-12-231-4/+5
| | | | | | | | | 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
* [Hexagon] Adding word loads.Colin LeMahieu2014-12-236-46/+38
| | | | llvm-svn: 224775
* [Hexagon] Adding signed halfword loads.Colin LeMahieu2014-12-235-30/+20
| | | | llvm-svn: 224774
* [Hexagon] Adding unsigned halfword load.Colin LeMahieu2014-12-235-20/+18
| | | | llvm-svn: 224772
* [mips][microMIPS] Implement LWSP and SWSP instructionsJozef Kolek2014-12-236-0/+90
| | | | | | Differential Revision: http://reviews.llvm.org/D6416 llvm-svn: 224771
* [ValueTracking] Move GlobalAlias handling to be after the max depth check in ↵Michael Kuperstein2014-12-231-15/+14
| | | | | | | | | | | | 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-233-81/+101
| | | | | | | | by Asaf Badouh http://reviews.llvm.org/D6456 llvm-svn: 224764
* [PowerPC] Don't mark the return-address slot as immutableHal Finkel2014-12-231-1/+1
| | | | | | | | | | | | | 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-232-2/+3
| | | | | | Added more intrinsics and encoding tests. llvm-svn: 224760
* [DagCombine] Improve DAGCombiner BUILD_VECTOR when it has two sources of ↵Michael Kuperstein2014-12-231-12/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-231-0/+2
| | | | | | | | | | 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-231-30/+30
| | | | | | | | | | - 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-231-2/+47
| | | | | | | | | | | | | | | | | | 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
* Revert r224739: Debug info: Teach SROA how to update debug info forChandler Carruth2014-12-231-30/+1
| | | | | | | | | | | 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-231-8/+3
| | | | | | | | | | | 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-223-100/+163
| | | | | | | | | | | | | | | | 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-221-7/+14
| | | | | | | | | | | | | 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
* [SROA] Lift the logic for traversing the alloca slices one partition atChandler Carruth2014-12-221-157/+303
| | | | | | | | | | | | | | | | | | | | | | | | a time into a partition iterator and a Partition class. There is a lot of knock-on simplification that this enables, largely stemming from having a Partition object to refer to in lots of helpers. I've only done a minimal amount of that because enoguh stuff is changing as-is in this commit. This shouldn't change any observable behavior. I've worked hard to preserve the *exact* traversal semantics which were originally present even though some of them make no sense. I'll be changing some of this in subsequent commits now that the logic is carefully factored into a reusable place. The primary motivation for this change is to break the rewriting into phases in order to support more intelligent rewriting. For example, I'm planning to change how split loads and stores are rewritten to remove the significant overuse of integer bit packing in the resulting code and allow more effective secondary splitting of aggregates. For any of this to work, they have to share the exact traversal logic. llvm-svn: 224742
* [LCSSA] Handle PHI insertion in disjoint loopsBruno Cardoso Lopes2014-12-223-10/+44
| | | | | | | | | | | | | | | | | | | | Take two disjoint Loops L1 and L2. LoopSimplify fails to simplify some loops (e.g. when indirect branches are involved). In such situations, it can happen that an exit for L1 is the header of L2. Thus, when we create PHIs in one of such exits we are also inserting PHIs in L2 header. This could break LCSSA form for L2 because these inserted PHIs can also have uses in L2 exits, which are never handled in the current implementation. Provide a fix for this corner case and test that we don't assert/crash on that. Differential Revision: http://reviews.llvm.org/D6624 rdar://problem/19166231 llvm-svn: 224740
* Debug info: Teach SROA how to update debug info for fragmented variables.Adrian Prantl2014-12-221-1/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows us to generate debug info for extremely advanced code such as typedef struct { long int a; int b;} S; int foo(S s) { return s.b; } which at -O1 on x86_64 is codegen'd into define i32 @foo(i64 %s.coerce0, i32 %s.coerce1) #0 { ret i32 %s.coerce1, !dbg !24 } with this patch we emit the following debug info for this TAG_formal_parameter [3] AT_location( 0x00000000 0x0000000000000000 - 0x0000000000000006: rdi, piece 0x00000008, rsi, piece 0x00000004 0x0000000000000006 - 0x0000000000000008: rdi, piece 0x00000008, rax, piece 0x00000004 ) AT_name( "s" ) AT_decl_file( "/Volumes/Data/llvm/_build.ninja.release/test.c" ) Thanks to chandlerc, dblaikie, and echristo for their feedback on all previous iterations of this patch! llvm-svn: 224739
* Fix Windows unwind info for functions in sections other than .textReid Kleckner2014-12-221-33/+26
| | | | | | | | | | | Previously we assumed the section name had the form .text$foo, which is what we used to do for inline functions. If the dollar wasn't present, we'd put unwind data in the .pdata and .xdata sections for the main .text section, which is incorrect. Fixes PR22001. llvm-svn: 224738
* [Hexagon] Adding memb instruction. Fixing whitespace in test from 224730.Colin LeMahieu2014-12-224-28/+18
| | | | llvm-svn: 224735
* [Hexagon] Adding classes and load unsigned byte instruction, updating usages.Colin LeMahieu2014-12-226-28/+123
| | | | llvm-svn: 224730
* [x86] Add vector @llvm.ctpop intrinsic custom loweringBruno Cardoso Lopes2014-12-221-0/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, when ctpop is supported for scalar types, the expansion of @llvm.ctpop.vXiY uses vector element extractions, insertions and individual calls to @llvm.ctpop.iY. When not, expansion with bit-math operations is used for the scalar calls. Local haswell measurements show that we can improve vector @llvm.ctpop.vXiY expansion in some cases by using a using a vector parallel bit twiddling approach, based on: v = v - ((v >> 1) & 0x55555555); v = (v & 0x33333333) + ((v >> 2) & 0x33333333); v = ((v + (v >> 4) & 0xF0F0F0F) v = v + (v >> 8) v = v + (v >> 16) v = v & 0x0000003F (from http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallel) When scalar ctpop isn't supported, the approach above performs better for v2i64, v4i32, v4i64 and v8i32 (see numbers below). And even when scalar ctpop is supported, this approach performs ~2x better for v8i32. Here, x86_64 implies -march=corei7-avx without ctpop and x86_64h includes ctpop support with -march=core-avx2. == [x86_64h - new] v8i32: 0.661685 v4i32: 0.514678 v4i64: 0.652009 v2i64: 0.324289 == [x86_64h - old] v8i32: 1.29578 v4i32: 0.528807 v4i64: 0.65981 v2i64: 0.330707 == [x86_64 - new] v8i32: 1.003 v4i32: 0.656273 v4i64: 1.11711 v2i64: 0.754064 == [x86_64 - old] v8i32: 2.34886 v4i32: 1.72053 v4i64: 1.41086 v2i64: 1.0244 More work for other vector types will come next. llvm-svn: 224725
OpenPOWER on IntegriCloud