summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Recognize mftbl as alias for mftb, for symmetry with mttb.Joerg Sonnenberger2014-08-041-0/+1
| | | | llvm-svn: 214769
* Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-08-043-4/+34
| | | | | | | | | | | | | | instructions within a function, lead to the function itself." Originally reverted in r213432 with flakey failures on an ASan self-host build. After reduction it seems to be the same issue fixed in r213805 (ArgPromo + DebugInfo: Handle updating debug info over multiple applications of argument promotion) and r213952 (by having LiveDebugVariables strip dbg_value intrinsics in functions that are not described by debug info). Though I cannot explain why this failure was flakey... llvm-svn: 214761
* R600/SI: Fix definitions for ds_read2 / ds_write2 instructions.Matt Arsenault2014-08-042-3/+4
| | | | | | | These were just wrong, using the wrong register classes and store2 was missing an operand. llvm-svn: 214756
* Rename PPCLinuxMCAsmInfo to PPCELFMCAsmInfo to better reflect theJoerg Sonnenberger2014-08-043-5/+5
| | | | | | systems it represents. llvm-svn: 214755
* Allow .lcomm with alignment on ELF targets.Joerg Sonnenberger2014-08-041-0/+1
| | | | llvm-svn: 214754
* Coverage: add HasCodeBefore flag to a mapping region.Alex Lorenz2014-08-042-7/+15
| | | | | | | | | This flag will be used by the coverage tool to help compute the execution counts for each line in a source file. Differential Revision: http://reviews.llvm.org/D4746 llvm-svn: 214740
* Move the R600 intrinsic support back to the target machine - there'sEric Christopher2014-08-044-6/+4
| | | | | | | nothing subtarget dependent about the intrinsic support in any backend as far as I can tell. llvm-svn: 214738
* Path: Stop claiming path::const_iterator is bidirectionalJustin Bogner2014-08-041-12/+27
| | | | | | | | | | | | | | | | | | | | | | path::const_iterator claims that it's a bidirectional iterator, but it doesn't satisfy all of the contracts for a bidirectional iterator. For example, n3376 24.2.5 p6 says "If a and b are both dereferenceable, then a == b if and only if *a and *b are bound to the same object", but this doesn't work with how we stash and recreate Components. This means that our use of reverse_iterator on this type is invalid and leads to many of the valgrind errors we're hitting, as explained by Tilmann Scheller here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140728/228654.html Instead, we admit that path::const_iterator is only an input_iterator, and implement a second input_iterator for path::reverse_iterator (by changing const_iterator::operator-- to reverse_iterator::operator++). All of the uses of this just traverse once over the path in one direction or the other anyway. llvm-svn: 214737
* Refactor SPRG instructions.Joerg Sonnenberger2014-08-041-35/+16
| | | | llvm-svn: 214733
* [X86] Place parentheses around "isMask_32(STReturns) && N <= 2".Akira Hatanaka2014-08-041-1/+1
| | | | | | This corrects r214672, which was committed to silence a gcc warning. llvm-svn: 214732
* Add support for m[ft][di]bat[ul] instructions.Joerg Sonnenberger2014-08-044-0/+33
| | | | llvm-svn: 214731
* Use the known address space constant rather than checking itMatt Arsenault2014-08-041-1/+1
| | | | llvm-svn: 214729
* R600: Remove unused includeMatt Arsenault2014-08-041-1/+0
| | | | llvm-svn: 214728
* Add a dummy subtarget to the CPP backend target machine. This willEric Christopher2014-08-041-3/+9
| | | | | | | allow us to forward all of the standard TargetMachine calls to the subtarget and still return null as we were before. llvm-svn: 214727
* Add features for PPC 4xx and e500/e500mc instructions.Joerg Sonnenberger2014-08-044-4/+18
| | | | | | Move the test cases for them into separate files. llvm-svn: 214724
* [SKX] Enabling load/store instructions: encodingRobert Khasanov2014-08-043-127/+206
| | | | | | | | Instructions: VMOVAPD, VMOVAPS, VMOVDQA8, VMOVDQA16, VMOVDQA32,VMOVDQA64, VMOVDQU8, VMOVDQU16, VMOVDQU32,VMOVDQU64, VMOVUPD, VMOVUPS, Reviewed by Elena Demikhovsky <elena.demikhovsky@intel.com> llvm-svn: 214719
* [PowerPC] Swap arguments to vpkuhum/vpkuwum on little-endianUlrich Weigand2014-08-043-36/+68
| | | | | | | | | | | | | In commit r213915, Bill fixed little-endian usage of vmrgh* and vmrgl* by swapping the input arguments. As it turns out, the exact same fix is also required for the vpkuhum/vpkuwum patterns. This fixes another regression in llvmpipe when vector support is enabled. Reviewed by Bill Schmidt. llvm-svn: 214718
* Improving the name of the function parameter, which happens to solve two ↵Aaron Ballman2014-08-041-14/+14
| | | | | | likely-less-than-useful MSVC warnings: warning C4258: 'I' : definition from the for loop is ignored; the definition from the enclosing scope is used. llvm-svn: 214717
* [PowerPC] MULHU/MULHS are not legal for vector typesUlrich Weigand2014-08-041-0/+2
| | | | | | | | | | I ran into some test failures where common code changed vector division by constant into a multiply-high operation (MULHU). But these are not implemented by the back-end, so we failed to recognize the insn. Fixed by marking MULHU/MULHS as Expand for vector types. llvm-svn: 214716
* [PowerPC] Fix and improve vector comparisonsUlrich Weigand2014-08-042-150/+111
| | | | | | | | | | | | | | | | | | | | This patch refactors code generation of vector comparisons. This fixes a wrong code-gen bug for ISD::SETGE for floating-point types, and improves generated code for vector comparisons in general. Specifically, the patch moves all logic deciding how to implement vector comparisons into getVCmpInst, which gets two extra boolean outputs indicating to its caller whether its needs to swap the input operands and/or negate the result of the comparison. Apart from implementing these two modifications as directed by getVCmpInst, there is no need to ever implement vector comparisons in any other manner; in particular, there is never a need to perform two separate comparisons (e.g. one for equal and one for greater-than, as code used to do before this patch). Reviewed by Bill Schmidt. llvm-svn: 214714
* [mips] Add assembler support for '.set mipsX'.Daniel Sanders2014-08-043-3/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch also fixes an issue with the way the Mips assembler enables/disables architecture features. Before this patch, the assembler never disabled feature bits. For example, .set mips64 .set mips32r2 would result in the 'OR' of mips64 with mips32r2 feature bits which isn't right. Unfortunately this isn't trivial to fix because there's not an easy way to clear feature bits as the algorithm in MCSubtargetInfo (ToggleFeature) only clears the bits that imply the feature being cleared and not the implied bits by the feature (there's a better explanation to the code I added). Patch by Matheus Almeida and updated by Toma Tabacu Reviewers: vmedic, matheusalmeida, dsanders Reviewed By: dsanders Subscribers: tomatabacu, llvm-commits Differential Revision: http://reviews.llvm.org/D4123 llvm-svn: 214709
* [x86] Just unilaterally prefer SSSE3-style PSHUFB lowerings over cleverChandler Carruth2014-08-041-35/+35
| | | | | | | | | | | | | | | use of PACKUS. It's cleaner that way. I looked at implementing clever combine-based folding of PACKUS chains into PSHUFB but it is quite hard and doesn't seem likely to be worth it. The most annoying part would be detecting that the correct masking had been done to use PACKUS-style instructions as a blend operation rather than there being any saturating as is indicated by its name. We generate really nice code for what few test cases I've come up with that aren't completely contrived for this by just directly prefering PSHUFB and so let's go with that strategy for now. =] llvm-svn: 214707
* [x86] Implement more aggressive use of PACKUS chains for lowering commonChandler Carruth2014-08-041-0/+106
| | | | | | | | | | | | | | patterns of v16i8 shuffles. This implements one of the more important FIXMEs for the SSE2 support in the new shuffle lowering. We now generate the optimal shuffle sequence for truncate-derived shuffles which show up essentially everywhere. Unfortunately, this exposes a weakness in other parts of the shuffle logic -- we can no longer form PSHUFB here. I'll add the necessary support for that and other things in a subsequent commit. llvm-svn: 214702
* Revert "r214669 - MachineCombiner Pass for selecting faster instruction"Kevin Qin2014-08-045-536/+13
| | | | | | This commit broke "make check" for several hours, so get it reverted. llvm-svn: 214697
* MemoryBuffer: Don't use mmap when FileSize is multiple of 4k on Cygwin.NAKAMURA Takumi2014-08-041-0/+8
| | | | | | | | | | | On Cygwin, getpagesize() returns 64k(AllocationGranularity). In r214580, the size of X86GenInstrInfo.inc became 1499136. FIXME: We should reorganize again getPageSize() on Win32. MapFile allocates address along AllocationGranularity but view is mapped by physical page. llvm-svn: 214681
* [x86] Handle single input shuffles in the SSSE3 case more intelligently.Chandler Carruth2014-08-041-0/+4
| | | | | | | | | | I spent some time looking into a better or more principled way to handle this. For example, by detecting arbitrary "unneeded" ORs... But really, there wasn't any point. We just shouldn't build blatantly wrong code so late in the pipeline rather than adding more stages and logic later on to fix it. Avoiding this is just too simple. llvm-svn: 214680
* [LLVM-C] Add LLVM{IsConstantString,GetAsString,GetElementAsConstant}.Peter Zotov2014-08-031-0/+16
| | | | llvm-svn: 214676
* [x86] Don't add nodes to the combined set (and prune subsequentChandler Carruth2014-08-031-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | combines) until they are legal. Doing it the old way could, when the stars align *just* right, cause a node to get into the combine set prior to being legalized. Then, when the same node showed up as an operand to another node later on (but not so much later on that it had been deleted as dead) we would fail to add it back to the worklist thinking it had already been combined. This would in turn cause it to not be legalized. Fortunately, we can also walk the operands looking for uncombined (and thus potentially un-legalized) nodes late. It will still ensure that we walk all operands of all nodes and send all of them through both the legalizer without changes and the combiner at least once. (Which was the original goal of this). I have a test case for this bug, but it is terribly brittle. For example, it will stop finding the bug the moment I enable the new shuffle lowering. I don't yet have any test case that reliably exercises this bug, and it isn't clear that it will be possible to craft one. It is entirely possible that with the new shuffle lowering the two forms of doing this are precisely equivalent. That doesn't mean we shouldn't take the more conservative approach of insisting on things in the combined set having survived the legalizer. llvm-svn: 214673
* X86: silence warning (-Wparentheses)Saleem Abdulrasool2014-08-031-1/+1
| | | | | | | | | GCC 4.8.2 points out the ambiguity in evaluation of the assertion condition: lib/Target/X86/X86FloatingPoint.cpp:949:49: warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses] assert(STReturns == 0 || isMask_32(STReturns) && N <= 2); llvm-svn: 214672
* CodeGen: silence a warningSaleem Abdulrasool2014-08-031-2/+1
| | | | | | | | GCC 4.8.2 objects to the tautological condition in the assert as the unsigned value is guaranteed to be >= 0. Simplify the assertion by dropping the tautological condition. llvm-svn: 214671
* fix for PR20354 - Miscompile of fabs due to vectorizationSanjay Patel2014-08-031-1/+5
| | | | | | | | | | This is intended to be the minimal change needed to fix PR20354 ( http://llvm.org/bugs/show_bug.cgi?id=20354 ). The check for a vector operation was wrong; we need to check that the fabs itself is not a vector operation. This patch will not generate the optimal code. A constant pool load and 'and' op will be generated instead of just returning a value that we can calculate in advance (as we do for the scalar case). I've put a 'TODO' comment for that here and expect to have that patch ready soon. There is a very similar optimization that we can do in visitFNEG, so I've put another 'TODO' there and expect to have another patch for that too. llvm-svn: 214670
* MachineCombiner Pass for selecting faster instructionGerolf Hoflehner2014-08-035-13/+536
| | | | | | | | | | | | | | | | | | | | | | sequence - AArch64 target support This patch turns off madd/msub generation in the DAGCombiner and generates them in the MachineCombiner instead. It replaces the original code sequence with the combined sequence when it is beneficial to do so. When there is no machine model support it always generates the madd/msub instruction. This is true also when the objective is to optimize for code size: when the combined sequence is shorter is always chosen and does not get evaluated. When there is a machine model the combined instruction sequence is evaluated for critical path and resource length using machine trace metrics and the original code sequence is replaced when it is determined to be faster. rdar://16319955 llvm-svn: 214669
* MachineCombiner Pass for selecting faster instructionGerolf Hoflehner2014-08-035-14/+503
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sequence - target independent framework When the DAGcombiner selects instruction sequences it could increase the critical path or resource len. For example, on arm64 there are multiply-accumulate instructions (madd, msub). If e.g. the equivalent multiply-add sequence is not on the crictial path it makes sense to select it instead of the combined, single accumulate instruction (madd/msub). The reason is that the conversion from add+mul to the madd could lengthen the critical path by the latency of the multiply. But the DAGCombiner would always combine and select the madd/msub instruction. This patch uses machine trace metrics to estimate critical path length and resource length of an original instruction sequence vs a combined instruction sequence and picks the faster code based on its estimates. This patch only commits the target independent framework that evaluates and selects code sequences. The machine instruction combiner is turned off for all targets and expected to evolve over time by gradually handling DAGCombiner pattern in the target specific code. This framework lays the groundwork for fixing rdar://16319955 llvm-svn: 214666
* MC: virtualise EmitWindowsUnwindTablesSaleem Abdulrasool2014-08-032-4/+7
| | | | | | | | | This makes EmitWindowsUnwindTables a virtual function and lowers the implementation of the function to the X86WinCOFFStreamer. This method is a target specific operation. This enables making the behaviour target dependent by isolating it entirely to the target specific streamer. llvm-svn: 214664
* MC: rename Win64EHFrameInfo to WinEH::FrameInfoSaleem Abdulrasool2014-08-033-26/+38
| | | | | | | | | | | | | | The frame information stored in this structure is driven by the requirements for Windows NT unwinding rather than Windows 64 specifically. As a result, this type can be shared across multiple architectures (ARM, AXP, MIPS, PPC, SH). Rename this class in preparation for adding support for supporting unwinding information for Windows on ARM. Take the opportunity to constify the members as everything except the ChainedParent is read-only. This required some adjustment to the label handling. llvm-svn: 214663
* R600/SI: Fix extra whitespace in asm strMatt Arsenault2014-08-031-1/+1
| | | | | | | | | This slipped in in r214467, so something like V_MOV_B32_e32 v0, ... is now printed with 2 spaces between the instruction name and first operand. llvm-svn: 214660
* [SimplifyCFG] fix accessing deleted PHINodes in switch-to-table conversion.Manman Ren2014-08-021-1/+4
| | | | | | | | | When we have a covered lookup table, make sure we don't delete PHINodes that are cached in PHIs. rdar://17887153 llvm-svn: 214642
* tlbia supportJoerg Sonnenberger2014-08-022-0/+4
| | | | llvm-svn: 214640
* mfdcr / mtdcr supportJoerg Sonnenberger2014-08-021-0/+5
| | | | llvm-svn: 214639
* fix bug 20513 - Crash in SLP VectorizerErik Eckstein2014-08-021-10/+14
| | | | llvm-svn: 214638
* Don't use additional arguments for dss and friends to satisfy DSS_Form,Joerg Sonnenberger2014-08-022-63/+54
| | | | | | | | | when let can do the same thing. Keep the 64bit variants as codegen-only. While they have a different register class, the encoding is the same for 32bit and 64bit mode. Having both present would otherwise confuse the disassembler. llvm-svn: 214636
* [AArch64] Teach DAGCombiner that converting two consecutive loads into a ↵James Molloy2014-08-021-0/+7
| | | | | | | | vector load is not a good transform when paired loads are available. The combiner was creating Q-register loads and stores, which then had to be spilled because there are no callee-save Q registers! llvm-svn: 214634
* [x86] Remove the FIXME that was implemented in r214628. Managed toChandler Carruth2014-08-021-4/+0
| | | | | | forget to update the comment here... =/ llvm-svn: 214630
* [x86] Largely complete the use of PSHUFB in the new vector shuffleChandler Carruth2014-08-023-14/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lowering with a small addition to it and adding PSHUFB combining. There is one obvious place in the new vector shuffle lowering where we should form PSHUFBs directly: when without them we will unpack a vector of i8s across two different registers and do a potentially 4-way blend as i16s only to re-pack them into i8s afterward. This is the crazy expensive fallback path for i8 shuffles and we can just directly use pshufb here as it will always be cheaper (the unpack and pack are two instructions so even a single shuffle between them hits our three instruction limit for forming PSHUFB). However, this doesn't generate very good code in many cases, and it leaves a bunch of common patterns not using PSHUFB. So this patch also adds support for extracting a shuffle mask from PSHUFB in the X86 lowering code, and uses it to handle PSHUFBs in the recursive shuffle combining. This allows us to combine through them, combine multiple ones together, and generally produce sufficiently high quality code. Extracting the PSHUFB mask is annoyingly complex because it could be either pre-legalization or post-legalization. At least this doesn't have to deal with re-materialized constants. =] I've added decode routines to handle the different patterns that show up at this level and we dispatch through them as appropriate. The two primary test cases are updated. For the v16 test case there is still a lot of room for improvement. Since I was going through it systematically I left behind a bunch of FIXME lines that I'm hoping to turn into ALL lines by the end of this. llvm-svn: 214628
* [x86] Switch to using the variable we extracted this operand into.Chandler Carruth2014-08-021-1/+1
| | | | | | | Spotted this missed refactoring by inspection when reading code, and it doesn't changethe functionality at all. llvm-svn: 214627
* [x86] Fix a few typos in my comments spotted in passing.Chandler Carruth2014-08-021-3/+3
| | | | llvm-svn: 214626
* [x86] Teach the target shuffle mask extraction to recognize unary formsChandler Carruth2014-08-021-6/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of normally binary shuffle instructions like PUNPCKL and MOVLHPS. This detects cases where a single register is used for both operands making the shuffle behave in a unary way. We detect this and adjust the mask to use the unary form which allows the existing DAG combine for shuffle instructions to actually work at all. As a consequence, this uncovered a number of obvious bugs in the existing DAG combine which are fixed. It also now canonicalizes several shuffles even with the existing lowering. These typically are trying to match the shuffle to the domain of the input where before we only really modeled them with the floating point variants. All of the cases which change to an integer shuffle here have something in the integer domain, so there are no more or fewer domain crosses here AFAICT. Technically, it might be better to go from a GPR directly to the floating point domain, but detecting floating point *outputs* despite integer inputs is a lot more code and seems unlikely to be worthwhile in practice. If folks are seeing domain-crossing regressions here though, let me know and I can hack something up to fix it. Also as a consequence, a bunch of missed opportunities to form pshufb now can be formed. Notably, splats of i8s now form pshufb. Interestingly, this improves the existing splat lowering too. We go from 3 instructions to 1. Yes, we may tie up a register, but it seems very likely to be worth it, especially if splatting the 0th byte (the common case) as then we can use a zeroed register as the mask. llvm-svn: 214625
* [x86] Teach my pshufb comment printer to handle VPSHUFB forms as well asChandler Carruth2014-08-021-2/+3
| | | | | | | PSHUFB forms. This will be important to update some AVX tests when I add PSHUFB combining. llvm-svn: 214624
* [SDAG] Refactor the code which deletes nodes in the DAG combiner to doChandler Carruth2014-08-021-54/+36
| | | | | | | | | | | | | so using a single helper which adds operands back onto the worklist. Several places didn't rigorously do this but a couple already did. Factoring them together and doing it rigorously is important to delete things recursively early on in the combiner and get a chance to see accurate hasOneUse values. While no existing test cases change, an upcoming patch to add DAG combining logic for PSHUFB requires this to work correctly. llvm-svn: 214623
* Fix issues with ISD::FNEG and ISD::FMA SDNodes where they would not be ↵Owen Anderson2014-08-021-0/+12
| | | | | | | | | | | | constant-folded during DAGCombine in certain circumstances. Unfortunately, the circumstances required to trigger the issue seem to require a pretty specific interaction of DAGCombines, and I haven't been able to find a testcase that reproduces on X86, ARM, or AArch64. The functionality added here is replicated in essentially every other DAG combine, so it seems pretty obviously correct. llvm-svn: 214622
OpenPOWER on IntegriCloud