summaryrefslogtreecommitdiffstats
path: root/llvm/test
Commit message (Collapse)AuthorAgeFilesLines
* AMDGCN/SI: Implement readlane/readfirstlane intrinsicsChangpeng Fang2016-08-242-0/+78
| | | | | | | | | | | | | | | Summary: This patch implements readlane/readfirstlane intrinsics. TODO: need to define a new register class to consider the case that the source could be a vector register or M0. Reviewed by: arsenm and tstellarAMD Differential Revision: http://reviews.llvm.org/D22489 llvm-svn: 279660
* Use isTargetMachO instead of isTargetDarwin.Rafael Espindola2016-08-241-0/+10
| | | | llvm-svn: 279655
* [X86][SSE] Add MINSD/MAXSD/MINSS/MAXSS intrinsic scalar load folding supportSimon Pilgrim2016-08-241-6/+46
| | | | | | These are no different in load behaviour to the existing ADD/SUB/MUL/DIV scalar ops but were missing from isNonFoldablePartialRegisterLoad llvm-svn: 279652
* DebugInfo: Add flag to CU to disable emission of inline debug info into the ↵David Blaikie2016-08-242-3/+44
| | | | | | | | | | skeleton CU In cases where .dwo/.dwp files are guaranteed to be available, skipping the extra online (in the .o file) inline info can save a substantial amount of space - see the original r221306 for more details there. llvm-svn: 279650
* [LV] Unify vector and scalar mapsMatthew Simpson2016-08-244-89/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch unifies the data structures we use for mapping instructions from the original loop to their corresponding instructions in the new loop. Previously, we maintained two distinct maps for this purpose: WidenMap and ScalarIVMap. WidenMap maintained the vector values each instruction from the old loop was represented with, and ScalarIVMap maintained the scalar values each scalarized induction variable was represented with. With this patch, all values created for the new loop are maintained in VectorLoopValueMap. The change allows for several simplifications. Previously, when an instruction was scalarized, we had to insert the scalar values into vectors in order to maintain the mapping in WidenMap. Then, if a user of the scalarized value was also scalar, we had to extract the scalar values from the temporary vector we created. We now aovid these unnecessary scalar-to-vector-to-scalar conversions. If a scalarized value is used by a scalar instruction, the scalar value is used directly. However, if the scalarized value is needed by a vector instruction, we generate the needed insertelement instructions on-demand. A common idiom in several locations in the code (including the scalarization code), is to first get the vector values an instruction from the original loop maps to, and then extract a particular scalar value. This patch adds getScalarValue for this purpose along side getVectorValue as an interface into VectorLoopValueMap. These functions work together to return the requested values if they're available or to produce them if they're not. The mapping has also be made less permissive. Entries can be added to VectorLoopValue map with the new initVector and initScalar functions. getVectorValue has been modified to return a constant reference to the mapped entries. There's no real functional change with this patch; however, in some cases we will generate slightly different code. For example, instead of an insertelement sequence following the definition of an instruction, it will now precede the first use of that instruction. This can be seen in the test case changes. Differential Revision: https://reviews.llvm.org/D23169 llvm-svn: 279649
* [SCCP] Don't delete side-effecting instructionsSanjoy Das2016-08-241-5/+15
| | | | | | | | I'm not sure if the `!isa<CallInst>(Inst) && !isa<TerminatorInst>(Inst))` bit is correct either, but this fixes the case we know is broken. llvm-svn: 279647
* [X86][SSE] Add support for combining VZEXT_MOVL target shufflesSimon Pilgrim2016-08-246-70/+32
| | | | | | | | | | Includes adding more general support for the pattern: VZEXT_MOVL(VZEXT_LOAD(ptr)) -> VZEXT_LOAD(ptr) This has unearthed a couple of latent poor codegen issues (MINSS/MAXSS scalar load folding and MOVDDUP/BROADCAST load folding patterns), which will be fixed shortly. Its also reduced a couple of tests so that they no longer reach the instruction threshold necessary to be combined to PSHUFB (see PR26183). llvm-svn: 279646
* GlobalISel: fix cmp test to be in SSA formTim Northover2016-08-241-19/+20
| | | | llvm-svn: 279633
* [ThinLTO/gold] Add caching support to gold-pluginTeresa Johnson2016-08-242-0/+27
| | | | | | | | | | | | | | Summary: With support now in the new LTO API for caching (r279576), add optional ThinLTO caching in the gold-plugin. Reviewers: mehdi_amini Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D23836 llvm-svn: 279631
* [X86][SSE] Regenerate scalar math load folding tests for 32 and 64 bit targetsSimon Pilgrim2016-08-241-50/+89
| | | | llvm-svn: 279630
* AMDGPU : Add V_SAD_U32 instruction pattern.Wei Ding2016-08-241-0/+283
| | | | | | Differential Revision: http://reviews.llvm.org/D23069 llvm-svn: 279629
* [llvm-cov] Add the project summary to each source file coverage report.Ying Yi2016-08-244-4/+60
| | | | | | | | | | | | This patch includes the following changes: - Included header "Code coverage report" and include the date that the report was created. - Included title (as specified in a command line option, (i.e llvm-cov -project-title="Simple Test") - In the summary, list the elf files that the source code file has contributed to. - Used column heading for "Line No.", "Count No.", Source". Differential Revision: https://reviews.llvm.org/D23345 llvm-svn: 279628
* Create subranges for new intervals resulting from live interval splittingKrzysztof Parzyszek2016-08-242-0/+256
| | | | | | | | | | | | | | | | | | | The register allocator can split a live interval of a register into a set of smaller intervals. After the allocation of registers is complete, the rewriter will modify the IR to replace virtual registers with the corres- ponding physical registers. At this stage, if a register corresponding to a subregister of a virtual register is used, the rewriter will check if that subregister is undefined, and if so, it will add the <undef> flag to the machine operand. The function verifying liveness of the subregis- ter would assume that it is undefined, unless any of the subranges of the live interval proves otherwise. The problem is that the live intervals created during splitting do not have any subranges, even if the original parent interval did. This could result in the <undef> flag placed on a register that is actually defined. Differential Revision: http://reviews.llvm.org/D21189 llvm-svn: 279625
* [mips] Preparatory work for a generic schedulerSimon Dardis2016-08-2415-63/+63
| | | | | | | | | | | | | Extend instruction definitions from nearly all ISAs to include appropriate instruction itineraries. Change MIPS16s gp prologue generation to use real instructions instead of using a pseudo instruction. Reviewers: dsanders, vkalintiris Differential Review: https://reviews.llvm.org/D23548 llvm-svn: 279623
* [X86][AVX2] Ensure on 32-bit targets that we broadcast f64 types not i64 ↵Simon Pilgrim2016-08-241-9/+46
| | | | | | (PR29101) llvm-svn: 279622
* [X86][F16C] Regenerated f16c testsSimon Pilgrim2016-08-242-44/+119
| | | | llvm-svn: 279621
* [Loop Vectorizer] Support predication of div/remGil Rapaport2016-08-243-27/+267
| | | | | | | | | | div/rem instructions in basic blocks that require predication currently prevent vectorization. This patch extends the existing mechanism for predicating stores to handle other instructions and leverages it to predicate divs and rems. Differential Revision: https://reviews.llvm.org/D22918 llvm-svn: 279620
* [PM] Introduce basic update capabilities to the new PM's CGSCC passChandler Carruth2016-08-244-17/+491
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | manager, including both plumbing and logic to handle function pass updates. There are three fundamentally tied changes here: 1) Plumbing *some* mechanism for updating the CGSCC pass manager as the CG changes while passes are running. 2) Changing the CGSCC pass manager infrastructure to have support for the underlying graph to mutate mid-pass run. 3) Actually updating the CG after function passes run. I can separate them if necessary, but I think its really useful to have them together as the needs of #3 drove #2, and that in turn drove #1. The plumbing technique is to extend the "run" method signature with extra arguments. We provide the call graph that intrinsically is available as it is the basis of the pass manager's IR units, and an output parameter that records the results of updating the call graph during an SCC passes's run. Note that "...UpdateResult" isn't a *great* name here... suggestions very welcome. I tried a pretty frustrating number of different data structures and such for the innards of the update result. Every other one failed for one reason or another. Sometimes I just couldn't keep the layers of complexity right in my head. The thing that really worked was to just directly provide access to the underlying structures used to walk the call graph so that their updates could be informed by the *particular* nature of the change to the graph. The technique for how to make the pass management infrastructure cope with mutating graphs was also something that took a really, really large number of iterations to get to a place where I was happy. Here are some of the considerations that drove the design: - We operate at three levels within the infrastructure: RefSCC, SCC, and Node. In each case, we are working bottom up and so we want to continue to iterate on the "lowest" node as the graph changes. Look at how we iterate over nodes in an SCC running function passes as those function passes mutate the CG. We continue to iterate on the "lowest" SCC, which is the one that continues to contain the function just processed. - The call graph structure re-uses SCCs (and RefSCCs) during mutation events for the *highest* entry in the resulting new subgraph, not the lowest. This means that it is necessary to continually update the current SCC or RefSCC as it shifts. This is really surprising and subtle, and took a long time for me to work out. I actually tried changing the call graph to provide the opposite behavior, and it breaks *EVERYTHING*. The graph update algorithms are really deeply tied to this particualr pattern. - When SCCs or RefSCCs are split apart and refined and we continually re-pin our processing to the bottom one in the subgraph, we need to enqueue the newly formed SCCs and RefSCCs for subsequent processing. Queuing them presents a few challenges: 1) SCCs and RefSCCs use wildly different iteration strategies at a high level. We end up needing to converge them on worklist approaches that can be extended in order to be able to handle the mutations. 2) The order of the enqueuing need to remain bottom-up post-order so that we don't get surprising order of visitation for things like the inliner. 3) We need the worklists to have set semantics so we don't duplicate things endlessly. We don't need a *persistent* set though because we always keep processing the bottom node!!!! This is super, super surprising to me and took a long time to convince myself this is correct, but I'm pretty sure it is... Once we sink down to the bottom node, we can't re-split out the same node in any way, and the postorder of the current queue is fixed and unchanging. 4) We need to make sure that the "current" SCC or RefSCC actually gets enqueued here such that we re-visit it because we continue processing a *new*, *bottom* SCC/RefSCC. - We also need the ability to *skip* SCCs and RefSCCs that get merged into a larger component. We even need the ability to skip *nodes* from an SCC that are no longer part of that SCC. This led to the design you see in the patch which uses SetVector-based worklists. The RefSCC worklist is always empty until an update occurs and is just used to handle those RefSCCs created by updates as the others don't even exist yet and are formed on-demand during the bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and we push new SCCs onto it and blacklist existing SCCs on it to get the desired processing. We then *directly* update these when updating the call graph as I was never able to find a satisfactory abstraction around the update strategy. Finally, we need to compute the updates for function passes. This is mostly used as an initial customer of all the update mechanisms to drive their design to at least cover some real set of use cases. There are a bunch of interesting things that came out of doing this: - It is really nice to do this a function at a time because that function is likely hot in the cache. This means we want even the function pass adaptor to support online updates to the call graph! - To update the call graph after arbitrary function pass mutations is quite hard. We have to build a fairly comprehensive set of data structures and then process them. Fortunately, some of this code is related to the code for building the cal graph in the first place. Unfortunately, very little of it makes any sense to share because the nature of what we're doing is so very different. I've factored out the one part that made sense at least. - We need to transfer these updates into the various structures for the CGSCC pass manager. Once those were more sanely worked out, this became relatively easier. But some of those needs necessitated changes to the LazyCallGraph interface to make it significantly easier to extract the changed SCCs from an update operation. - We also need to update the CGSCC analysis manager as the shape of the graph changes. When an SCC is merged away we need to clear analyses associated with it from the analysis manager which we didn't have support for in the analysis manager infrsatructure. New SCCs are easy! But then we have the case that the original SCC has its shape changed but remains in the call graph. There we need to *invalidate* the analyses associated with it. - We also need to invalidate analyses after we *finish* processing an SCC. But the analyses we need to invalidate here are *only those for the newly updated SCC*!!! Because we only continue processing the bottom SCC, if we split SCCs apart the original one gets invalidated once when its shape changes and is not processed farther so its analyses will be correct. It is the bottom SCC which continues being processed and needs to have the "normal" invalidation done based on the preserved analyses set. All of this is mostly background and context for the changes here. Many thanks to all the reviewers who helped here. Especially Sanjoy who caught several interesting bugs in the graph algorithms, David, Sean, and others who all helped with feedback. Differential Revision: http://reviews.llvm.org/D21464 llvm-svn: 279618
* Tentatively fix gold-plugin test: ThinLTO objects start at offset 0 now.Mehdi Amini2016-08-241-1/+1
| | | | | | Annoyingly, incremental builds don't detect these kind of issue. llvm-svn: 279612
* [Coroutines] Part 8: Coroutine Frame Building algorithmGor Nishanov2016-08-243-1/+114
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds coroutine frame building algorithm. Now, simple coroutines such as ex0.ll and ex1.ll (first examples from docs\Coroutines.rst can be compiled). Documentation and overview is here: http://llvm.org/docs/Coroutines.html. Upstreaming sequence (rough plan) 1.Add documentation. (https://reviews.llvm.org/D22603) 2.Add coroutine intrinsics. (https://reviews.llvm.org/D22659) ... 7. Split coroutine into subfunctions. (https://reviews.llvm.org/D23461) 8. Coroutine Frame Building algorithm <= we are here 9. Add f.cleanup subfunction. 10+. The rest of the logic Reviewers: majnemer Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D23586 llvm-svn: 279609
* CodeGen: Remove MachineFunctionAnalysis => Enable (Machine)ModulePassesMatthias Braun2016-08-242-2/+1
| | | | | | | | | | | | | | | | | | | | | | Re-apply this patch, hopefully I will get away without any warnings in the constructor now. This patch removes the MachineFunctionAnalysis. Instead we keep a map from IR Function to MachineFunction in the MachineModuleInfo. This allows the insertion of ModulePasses into the codegen pipeline without breaking it because the MachineFunctionAnalysis gets dropped before a module pass. Peak memory should stay unchanged without a ModulePass in the codegen pipeline: Previously the MachineFunction was freed at the end of a codegen function pipeline because the MachineFunctionAnalysis was dropped; With this patch the MachineFunction is freed after the AsmPrinter has finished. Differential Revision: http://reviews.llvm.org/D23736 llvm-svn: 279602
* MIRParser/MIRPrinter: Compute isSSA instead of printing/parsing it.Matthias Braun2016-08-2466-152/+2
| | | | | | | | | Specifying isSSA is an extra line at best and results in invalid MI at worst. Compute the value instead. Differential Revision: http://reviews.llvm.org/D22722 llvm-svn: 279600
* Revert r279564. It introduces undefined behavior (binding a reference to aRichard Smith2016-08-232-1/+2
| | | | | | | dereferenced null pointer) in MachineModuleInfo::MachineModuleInfo that causes -Werror builds (including several buildbots) to fail. llvm-svn: 279580
* GlobalISel: add some G_TRUNCs to make icmp test valid MIR.Tim Northover2016-08-231-11/+17
| | | | llvm-svn: 279579
* [MC] Support .dc directives in assembler parserPetr Hosek2016-08-231-0/+41
| | | | | | | | | | While these directives are mostly aliases for the existing integer and float value directives, some of them like .dc.a have no direct equivalents and are sometimes being used for convenience. Differential Revision: https://reviews.llvm.org/D23810 llvm-svn: 279577
* [ThinLTO] Add caching to the new LTO APIMehdi Amini2016-08-231-1/+9
| | | | | | | | | | | | Add the ability to plug a cache on the LTO API. I tried to write such that a linker implementation can control the cache backend. This is intrusive and I'm not totally happy with it, but I can't figure out a better design right now. Differential Revision: https://reviews.llvm.org/D23599 llvm-svn: 279576
* GlobalISel: add forgotten test-case for G_ICMPTim Northover2016-08-231-0/+45
| | | | llvm-svn: 279569
* GlobalISel: make truncate/extend casts uniformTim Northover2016-08-239-43/+43
| | | | | | | They really should have both types represented, but early variants were created before MachineInstrs could have multiple types so they're rather ambiguous. llvm-svn: 279567
* GlobalISel: legalize conditional branches on AArch64.Tim Northover2016-08-231-0/+10
| | | | llvm-svn: 279565
* CodeGen: Remove MachineFunctionAnalysis => Enable (Machine)ModulePassesMatthias Braun2016-08-232-2/+1
| | | | | | | | | | | | | | | | | | | | | | | Re-apply this commit with the deletion of a MachineFunction delegated to a separate pass to avoid use after free when doing this directly in AsmPrinter. This patch removes the MachineFunctionAnalysis. Instead we keep a map from IR Function to MachineFunction in the MachineModuleInfo. This allows the insertion of ModulePasses into the codegen pipeline without breaking it because the MachineFunctionAnalysis gets dropped before a module pass. Peak memory should stay unchanged without a ModulePass in the codegen pipeline: Previously the MachineFunction was freed at the end of a codegen function pipeline because the MachineFunctionAnalysis was dropped; With this patch the MachineFunction is freed after the AsmPrinter has finished. Differential Revision: http://reviews.llvm.org/D23736 llvm-svn: 279564
* [SLP] Avoid signed integer overflowMatthew Simpson2016-08-231-0/+4
| | | | | | | | | | | | | | | | | | | The test case included with r279125 exposed an existing signed integer overflow. Since getTreeCost can return INT_MAX, we can't sum this cost together with other costs, such as getReductionCost. This patch removes the possibility of assigning a cost of INT_MAX. Since we were previously using INT_MAX as an indicator for "should not vectorize", we now explicitly check this condition with "isTreeTinyAndNotFullyVectorizable" before computing a cost. This patch adds a run-line to the test case used for r279125 that ensures we don't vectorize. Previously, this line would vectorize the test case by chance due to undefined behavior in the cost calculation. Differential Revision: https://reviews.llvm.org/D23723 llvm-svn: 279562
* [LTO] Fix test following r279550Mehdi Amini2016-08-231-1/+1
| | | | | | | The output name changed, but it was passing locally using the old output still present in the build dir. llvm-svn: 279556
* GlobalISel: mark pointer casts legal on AArch64.Tim Northover2016-08-231-0/+29
| | | | llvm-svn: 279553
* [ThinLTO] Add a llvm-lto2 test to check that ODR type uniquing is enabled (NFC)Mehdi Amini2016-08-232-0/+45
| | | | | | | | This adds a test for r279532, thanks David Li for noticing :) Recommit r279545 after committing first a dependent patch. llvm-svn: 279551
* Revert "[ThinLTO] Add a llvm-lto2 test to check that ODR type uniquing is ↵Mehdi Amini2016-08-232-45/+0
| | | | | | | | enabled (NFC)" This reverts commit r279545, test is failing, my Output dir was dirty and making the test pass. llvm-svn: 279549
* GlobalISel: legalize 1-bit load/store and mark 8/16 bit variants legal on ↵Tim Northover2016-08-231-0/+84
| | | | | | AArch64. llvm-svn: 279548
* [ThinLTO] Add a llvm-lto2 test to check that ODR type uniquing is enabled (NFC)Mehdi Amini2016-08-232-0/+45
| | | | | | This adds a test for r279532, thanks David Li for noticing :) llvm-svn: 279545
* [InstSimplify] allow icmp with constant folds for splat vectors, part 2Sanjay Patel2016-08-231-60/+20
| | | | | | | | | | | | Completes the m_APInt changes for simplifyICmpWithConstant(). Other commits in this series: https://reviews.llvm.org/rL279492 https://reviews.llvm.org/rL279530 https://reviews.llvm.org/rL279534 https://reviews.llvm.org/rL279538 llvm-svn: 279543
* [InstSimplify] allow icmp with constant folds for splat vectors, part 1Sanjay Patel2016-08-231-4/+2
| | | | llvm-svn: 279538
* [InstSimplify] add tests to show missing vector icmp foldsSanjay Patel2016-08-231-0/+238
| | | | llvm-svn: 279534
* [InstSimplify] move icmp with constant tests to another file; NFCSanjay Patel2016-08-232-165/+222
| | | | | | | | | | | ...because like the corresponding code, this is just too big to keep adding to. And the next step is to add a vector version of each of these tests to show missed folds. Also, auto-generate CHECK lines and add comments for the tests that correspond to the source code. llvm-svn: 279530
* [X86][SSE] Demonstrate inability to recognise that (v)cvtpd2dq & ↵Simon Pilgrim2016-08-231-0/+38
| | | | | | (v)cvttpd2dq intrinsics implicitly zeroes the upper half of the xmm llvm-svn: 279527
* [Hexagon] Packetize return value setup with the return instructionKrzysztof Parzyszek2016-08-231-0/+37
| | | | | | Commit r279241 unintentionally reverted that ability. llvm-svn: 279526
* [X86][AVX] Updated fptosi_2f64_to_4i32 test to show missed opportunity to ↵Simon Pilgrim2016-08-231-2/+6
| | | | | | implicit zero the upper elements llvm-svn: 279521
* [X86][AVX] Add v2i32 fp to int conversion testsSimon Pilgrim2016-08-231-5/+80
| | | | llvm-svn: 279520
* [X86][AVX] Add AVX2/AVX512 fp to int conversion testsSimon Pilgrim2016-08-231-351/+924
| | | | llvm-svn: 279518
* [X86][SSE] Demonstrate inability to recognise that (v)cvtpd2ps intrinsics ↵Simon Pilgrim2016-08-231-0/+16
| | | | | | implicitly zeroes the upper half of the xmm llvm-svn: 279511
* [X86][SSE] Demonstrate inability to recognise that (v)cvtpd2ps implicitly ↵Simon Pilgrim2016-08-231-0/+61
| | | | | | zeroes the upper half of the xmm llvm-svn: 279508
* [ARM] Generate consistent frame records for Thumb2Oliver Stannard2016-08-2331-163/+413
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is not an official documented ABI for frame pointers in Thumb2, but we should try to emit something which is useful. We use r7 as the frame pointer for Thumb code, which currently means that if a function needs to save a high register (r8-r11), it will get pushed to the stack between the frame pointer (r7) and link register (r14). This means that while a stack unwinder can follow the chain of frame pointers up the stack, it cannot know the offset to lr, so does not know which functions correspond to the stack frames. To fix this, we need to push the callee-saved registers in two batches, with the first push saving the low registers, fp and lr, and the second push saving the high registers. This is already implemented, but previously only used for iOS. This patch turns it on for all Thumb2 targets when frame pointers are required by the ABI, and the frame pointer is r7 (Windows uses r11, so this isn't a problem there). If frame pointer elimination is enabled we still emit a single push/pop even if we need a frame pointer for other reasons, to avoid increasing code size. We must also ensure that lr is pushed to the stack when using a frame pointer, so that we end up with a complete frame record. Situations that could cause this were rare, because we already push lr in most situations so that we can return using the pop instruction. Differential Revision: https://reviews.llvm.org/D23516 llvm-svn: 279506
* Revert "(HEAD -> master, origin/master, origin/HEAD) CodeGen: Remove ↵Matthias Braun2016-08-232-1/+2
| | | | | | | | | | MachineFunctionAnalysis => Enable (Machine)ModulePasses" Reverting while tracking down a use after free. This reverts commit r279502. llvm-svn: 279503
OpenPOWER on IntegriCloud