summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* [Tail duplication] Handle source registers with subregistersKrzysztof Parzyszek2016-04-261-34/+80
| | | | | | | | | | | | | | When a block is tail-duplicated, the PHI nodes from that block are replaced with appropriate COPY instructions. When those PHI nodes contained use operands with subregisters, the subregisters were dropped from the COPY instructions, resulting in incorrect code. Keep track of the subregister information and use this information when remapping instructions from the duplicated block. Differential Revision: http://reviews.llvm.org/D19337 llvm-svn: 267583
* [CodeGenPrepare] use branch weight metadata to decide if a select should be ↵Sanjay Patel2016-04-262-11/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | turned into a branch This is part of solving PR27344: https://llvm.org/bugs/show_bug.cgi?id=27344 CGP should undo the SimplifyCFG transform for the same reason that earlier patches have used this same mechanism: it's possible that passes between SimplifyCFG and CGP may be able to optimize the IR further with a select in place. For the TLI hook default, >99% taken or not taken is chosen as the default threshold for a highly predictable branch. Even the most limited HW branch predictors will be correct on this branch almost all the time, so even a massive mispredict penalty perf loss would be overcome by the win from all the times the branch was predicted correctly. As a follow-up, we could make the default target hook less conservative by using the SchedMachineModel's MispredictPenalty. Or we could just let targets override the default by implementing the hook with that and other target-specific options. Note that trying to statically determine mispredict rates for close-to-balanced profile weight data is generally impossible if the HW is sufficiently advanced. Ie, 50/50 taken/not-taken might still be 100% predictable. Finally, note that this patch as-is will not solve PR27344 because the current __builtin_unpredictable() branch weight default values are 4 and 64. A proposal to change that is in D19435. Differential Revision: http://reviews.llvm.org/D19488 llvm-svn: 267572
* [CodeGenPrepare] don't convert an unpredictable select into control flowSanjay Patel2016-04-261-1/+2
| | | | | | | Suggested in the review of D19488: http://reviews.llvm.org/D19488 llvm-svn: 267504
* [PR27390] [CodeGen] Reject indexed loads in CombinerDAG.Marcin Koscielnicki2016-04-252-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | visitAND, when folding and (load) forgets to check which output of an indexed load is involved, happily folding the updated address output on the following testcase: target datalayout = "e-m:e-i64:64-n32:64" target triple = "powerpc64le-unknown-linux-gnu" %typ = type { i32, i32 } define signext i32 @_Z8access_pP1Tc(%typ* %p, i8 zeroext %type) { %b = getelementptr inbounds %typ, %typ* %p, i64 0, i32 1 %1 = load i32, i32* %b, align 4 %2 = ptrtoint i32* %b to i64 %3 = and i64 %2, -35184372088833 %4 = inttoptr i64 %3 to i32* %_msld = load i32, i32* %4, align 4 %zzz = add i32 %1, %_msld ret i32 %zzz } Fix this by checking ResNo. I've found a few more places that currently neglect to check for indexed load, and tightened them up as well, but I don't have test cases for them. In fact, they might not be triggerable at all, at least with current targets. Still, better safe than sorry. Differential Revision: http://reviews.llvm.org/D19202 llvm-svn: 267420
* [WinEH] Update SplitAnalysis::computeLastSplitPoint to cope with multiple EH ↵David Majnemer2016-04-252-14/+12
| | | | | | | | | | | | | | | | | | | successors We didn't have logic to correctly handle CFGs where there was more than one EH-pad successor (these are novel with WinEH). There were situations where a register was live in one exceptional successor but not another but the code as written would only consider the first exceptional successor it found. This resulted in split points which were insufficiently early if an invoke was present. This fixes PR27501. N.B. This removes getLandingPadSuccessor. llvm-svn: 267412
* [MachineCombiner] Support for floating-point FMA on ARM64 (re-commit r267098)Gerolf Hoflehner2016-04-243-3/+26
| | | | | | | | | | | | | | | | | | | The original patch caused crashes because it could derefence a null pointer for SelectionDAGTargetInfo for targets that do not define it. Evaluates fmul+fadd -> fmadd combines and similar code sequences in the machine combiner. It adds support for float and double similar to the existing integer implementation. The key features are: - DAGCombiner checks whether it should combine greedily or let the machine combiner do the evaluation. This is only supported on ARM64. - It gives preference to throughput over latency: the heuristic used is to combine always in loops. The targets decides whether the machine combiner should optimize for throughput or latency. - Supports for fmadd, f(n)msub, fmla, fmls patterns - On by default at O3 ffast-math llvm-svn: 267328
* [CodeGen] Teach DAG combine to fold select_cc seteq X, 0, sizeof(X), ↵Craig Topper2016-04-241-0/+35
| | | | | | | | ctlz_zero_undef(X) -> ctlz(X). InstCombine already does this for IR and X86 pattern matches this during isel. A follow up commit will remove the X86 patterns to allow this to be tested. llvm-svn: 267325
* DebugInfo: Remove MDString-based type referencesDuncan P. N. Exon Smith2016-04-234-35/+14
| | | | | | | | | | | | | | | | | | | | | | | | Eliminate DITypeIdentifierMap and make DITypeRef a thin wrapper around DIType*. It is no longer legal to refer to a DICompositeType by its 'identifier:', and DIBuilder no longer retains all types with an 'identifier:' automatically. Aside from the bitcode upgrade, this is mainly removing logic to resolve an MDString-based reference to an actualy DIType. The commits leading up to this have made the implicit type map in DICompileUnit's 'retainedTypes:' field superfluous. This does not remove DITypeRef, DIScopeRef, DINodeRef, and DITypeRefArray, or stop using them in DI-related metadata. Although as of this commit they aren't serving a useful purpose, there are patchces under review to reuse them for CodeView support. The tests in LLVM were updated with deref-typerefs.sh, which is attached to the thread "[RFC] Lazy-loading of debug info metadata": http://lists.llvm.org/pipermail/llvm-dev/2016-April/098318.html llvm-svn: 267296
* replace duplicated static functions for profile metadata access with ↵Sanjay Patel2016-04-231-25/+2
| | | | | | BranchInst member function; NFCI llvm-svn: 267295
* [CodeGen] When promoting CTTZ operations to larger type, don't insert a ↵Craig Topper2016-04-231-9/+11
| | | | | | select to detect if the input is zero to return the original size instead of the extended size. Instead just set the first bit in the zero extended part. llvm-svn: 267280
* Re-commit optimization bisect support (r267022) without new pass manager ↵Andrew Kaylor2016-04-2215-15/+18
| | | | | | | | | | support. The original commit was reverted because of a buildbot problem with LazyCallGraph::SCC handling (not related to the OptBisect handling). Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267231
* Introduce llvm.load.relative intrinsic.Peter Collingbourne2016-04-224-0/+89
| | | | | | | | | | | | | | | | | | | This intrinsic takes two arguments, ``%ptr`` and ``%offset``. It loads a 32-bit value from the address ``%ptr + %offset``, adds ``%ptr`` to that value and returns it. The constant folder specifically recognizes the form of this intrinsic and the constant initializers it may load from; if a loaded constant initializer is known to have the form ``i32 trunc(x - %ptr)``, the intrinsic call is folded to ``x``. LLVM provides that the calculation of such a constant initializer will not overflow at link time under the medium code model if ``x`` is an ``unnamed_addr`` function. However, it does not provide this guarantee for a constant initializer folded into a function body. This intrinsic can be used to avoid the possibility of overflows when loading from such a constant. Differential Revision: http://reviews.llvm.org/D18367 llvm-svn: 267223
* TLI: Only iterate over integer vector typesMatt Arsenault2016-04-221-4/+3
| | | | | | Instead of iterating over all vectors and skipping integers. llvm-svn: 267220
* DAGCombiner: Relax alignment restriction when changing store typeMatt Arsenault2016-04-221-10/+14
| | | | | | If the target allows the alignment, this should be OK. llvm-svn: 267217
* CodeGen: Use PLT relocations for relative references to unnamed_addr functions.Peter Collingbourne2016-04-222-5/+46
| | | | | | | | | | | | | The relative vtable ABI (PR26723) needs PLT relocations to refer to virtual functions defined in other DSOs. The unnamed_addr attribute means that the function's address is not significant, so we're allowed to substitute it with the address of a PLT entry. Also includes a bonus feature: addends for COFF image-relative references. Differential Revision: http://reviews.llvm.org/D17938 llvm-svn: 267211
* DAGCombiner: Relax alignment restriction when changing load typeMatt Arsenault2016-04-221-3/+4
| | | | | | If the target allows the alignment, this should still be OK. llvm-svn: 267209
* MachineScheduler: Move code to initialize a Candidate out of tryCandidate(); NFCMatthias Braun2016-04-221-33/+33
| | | | llvm-svn: 267191
* MachineScheduler: Limit the size of the ready list.Matthias Braun2016-04-221-1/+10
| | | | | | | | | Avoid quadratic complexity in unusually large basic blocks by limiting the size of the ready lists. Differential Revision: http://reviews.llvm.org/D19349 llvm-svn: 267189
* PostRAHazardRecocgnizer: Fix unused-private-field warningTom Stellard2016-04-221-1/+0
| | | | llvm-svn: 267160
* CodeGen: Add a stand-alone hazard recognizer passTom Stellard2016-04-223-0/+103
| | | | | | | | | | | | | | | | Summary: This new pass allows targets to use the hazard recognizer without having to also run one of the schedulers. This is useful when compiling with optimizations disabled for targets that still need noop hazards to be handled correctly. Reviewers: hfinkel, atrick Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D18594 llvm-svn: 267156
* Fix -Wunused-variable in non-asserts build.Eric Liu2016-04-221-0/+1
| | | | llvm-svn: 267128
* Revert r267098 - [MachineCombiner] Support for floating-point FMA on ARM64Daniel Sanders2016-04-223-27/+4
| | | | | | It introduced buildbot failures on clang-cmake-mips, clang-ppc64le-linux, among others. llvm-svn: 267127
* Revert "Initial implementation of optimization bisect support."Vedant Kumar2016-04-2215-18/+15
| | | | | | | | This reverts commit r267022, due to an ASan failure: http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/1549 llvm-svn: 267115
* AMDGPU/SI: add llvm.amdgcn.ps.live intrinsicNicolai Haehnle2016-04-221-0/+11
| | | | | | | | | | | | | | | | | | | | | | | Summary: This intrinsic returns true if the current thread belongs to a live pixel and false if it belongs to a pixel that we are executing only for derivative computation. It will be used by Mesa to implement gl_HelperInvocation. Note that for pixels that are killed during the shader, this implementation also returns true, but it doesn't matter because those pixels are always disabled in the EXEC mask. This unearthed a corner case in the instruction verifier, which complained about a v_cndmask 0, 1, exec, exec<imp-use> instruction. That's stupid but correct code, so make the verifier accept it as such. Reviewers: arsenm, tstellarAMD Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D19191 llvm-svn: 267102
* [MachineCombiner] Support for floating-point FMA on ARM64Gerolf Hoflehner2016-04-223-4/+27
| | | | | | | | | | | | | | | | Evaluates fmul+fadd -> fmadd combines and similar code sequences in the machine combiner. It adds support for float and double similar to the existing integer implementation. The key features are: - DAGCombiner checks whether it should combine greedily or let the machine combiner do the evaluation. This is only supported on ARM64. - It gives preference to throughput over latency: the heuristic used is to combine always in loops. The targets decides whether the machine combiner should optimize for throughput or latency. - Supports for fmadd, f(n)msub, fmla, fmls patterns - On by default at O3 ffast-math llvm-svn: 267098
* Fix more -Wunused-variable in non-asserts build.David Blaikie2016-04-211-3/+2
| | | | llvm-svn: 267077
* Fix some -Wunused-variable warnings in non-asserts builds.David Blaikie2016-04-211-5/+6
| | | | llvm-svn: 267073
* Improve error message reporting for MachineFunctionPropertiesDerek Schuff2016-04-212-2/+4
| | | | | | | | When printing the properties required by a pass, only print the properties that are set, and not those that are clear (only properties that are set are verified, clear properties are "don't-care"). llvm-svn: 267070
* [MachineBasicBlock] Make the pass argument truly mandatory whenQuentin Colombet2016-04-214-10/+10
| | | | | | | | | | | | | | splitting edges. MachineBasicBlock::SplitCriticalEdges will crash if a nullptr would have been passed for the Pass argument. Do not allow that by turning this argument into a reference. The alternative would have been to make the Pass a truly optional argument, but although this is easy to do, I was afraid users using it like this would not be aware the livness information, dominator tree and such would silently be broken. llvm-svn: 267052
* [MachineBasicBlock] Refactor SplitCriticalEdge to expose a query API.Quentin Colombet2016-04-211-27/+39
| | | | | | | | | Introduce canSplitCriticalEdge, so that clients can now query whether or not a critical edge can be split without actually needing to split it. This may be useful when gathering information for cost models for instance. llvm-svn: 267046
* [RegisterBankInfo] Change the API for the verify methods.Quentin Colombet2016-04-213-10/+15
| | | | | | | Return bool instead of void so that it is natural to put the calls into asserts. llvm-svn: 267033
* LegalizeDAG: Move unaligned load/store expansion to TLIMatt Arsenault2016-04-212-310/+304
| | | | | | | | When custom lowered, this is not called if the store is custom lowered. Move it to be a utility function so targets can easily expand unaligned accesses when custom lowering. llvm-svn: 267029
* [RegisterBankInfo] Change the representation of the partial mappings.Quentin Colombet2016-04-212-33/+26
| | | | | | | | | Instead of holding a mask, hold two value: the start index and the length of the mapping. This is a more compact representation, although less powerful. That being said, arbitrary masks would not have worked for the generic so do not allow them in the first place. llvm-svn: 267025
* DAGCombiner: Reduce 64-bit BFE pattern to pattern on 32-bit componentMatt Arsenault2016-04-211-0/+44
| | | | | | | If the extracted bits are restricted to the upper half or lower half, this can be truncated. llvm-svn: 267024
* Initial implementation of optimization bisect support.Andrew Kaylor2016-04-2115-15/+18
| | | | | | | | | | | | This patch implements a optimization bisect feature, which will allow optimizations to be selectively disabled at compile time in order to track down test failures that are caused by incorrect optimizations. The bisection is enabled using a new command line option (-opt-bisect-limit). Individual passes that may be skipped call the OptBisect object (via an LLVMContext) to see if they should be skipped based on the bisect limit. A finer level of control (disabling individual transformations) can be managed through an addition OptBisect method, but this is not yet used. The skip checking in this implementation is based on (and replaces) the skipOptnoneFunction check. Where that check was being called, a new call has been inserted in its place which checks the bisect limit and the optnone attribute. A new function call has been added for module and SCC passes that behaves in a similar way. Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267022
* Fixed Dwarf debug info emission to skip DILexicalBlockFile entries.Amjad Aboud2016-04-212-8/+14
| | | | | | | | Before this fix, DILexicalBlockFile entries were skipped only in some cases and were not in other cases. Differential Revision: http://reviews.llvm.org/D18724 llvm-svn: 267004
* [SelectionDAG] Teach LegalizeVectorOps to directly Expand ↵Craig Topper2016-04-211-3/+5
| | | | | | | | CTTZ_ZERO_UNDEF/CTLZ_ZERO_UNDEF to CTTZ/CTLZ directly if those ops are Legal/Custom instead of deferring it to LegalizeOps. This is needed to support CTTZ/CTLZ Custom correctly since LegalizeOps would be too late to do the custom lowering. llvm-svn: 266951
* MachineSched: Cleanup; NFCMatthias Braun2016-04-211-32/+16
| | | | llvm-svn: 266946
* ScoreboardHazardRecognizer: unbreak TSAN by moving a static mutated variable ↵Mehdi Amini2016-04-201-15/+6
| | | | | | | to a member From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266837
* [PPC, SSP] Support PowerPC Linux stack protection.Tim Shen2016-04-192-14/+12
| | | | llvm-svn: 266809
* [SSP, 2/2] Create llvm.stackguard() intrinsic and lower it to LOAD_STACK_GUARDTim Shen2016-04-194-78/+94
| | | | | | | | | | | | | | | | | | | | | | | With this change, ideally IR pass can always generate llvm.stackguard call to get the stack guard; but for now there are still IR form stack guard customizations around (see getIRStackGuard()). Future SSP customization should go through LOAD_STACK_GUARD. There is a behavior change: stack guard values are not CSEed anymore, since we should never reuse the value in case that it has been spilled (and corrupted). See ssp-guard-spill.ll. This also cause the change of stack size and codegen in X86 and AArch64 test cases. Ideally we'd like to know if the guard created in llvm.stackprotector() gets spilled or not. If the value is spilled, discard the value and reload stack guard; otherwise reuse the value. This can be done by teaching register allocator to know how to rematerialize LOAD_STACK_GUARD and force a rematerialization (which seems hard), or check for spilling in expandPostRAPseudo. It only makes sense when the stack guard is a global variable, which requires more instructions to load. Anyway, this seems to go out of the scope of the current patch. llvm-svn: 266806
* Add a description for the PatchableFunction pass; NFCSanjoy Das2016-04-191-1/+2
| | | | llvm-svn: 266721
* Introduce a "patchable-function" function attributeSanjoy Das2016-04-194-0/+74
| | | | | | | | | | | | | | | | | Summary: The `"patchable-function"` attribute can be used by an LLVM client to influence LLVM's code generation in ways that makes the generated code easily patchable at runtime (for instance, to redirect control). Right now only one patchability scheme is supported, `"prologue-short-redirect"`, but this can be expanded in the future. Reviewers: joker.eph, rnk, echristo, dberris Subscribers: joker.eph, echristo, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19046 llvm-svn: 266715
* [DWARF] Force a linkage_name on an inlined subprogram's abstract origin.Paul Robinson2016-04-184-18/+30
| | | | | | | | | | | | | When we suppress linkage names, for a non-inlined subprogram the name can still be found in the object-file symbol table, because we have the code address of the subprogram. This is not necessarily the case for an inlined subprogram, so we still want to emit the linkage name in the DWARF. Put this on the abstract-origin DIE because it's common to all inlined instances. Differential Revision: http://reviews.llvm.org/D18706 llvm-svn: 266692
* NFC: unify clang / LLVM atomic orderingJF Bastien2016-04-181-38/+8
| | | | | | | | | | | This makes the C11 / C++11 *ABI* atomic ordering accessible from LLVM, as discussed in http://reviews.llvm.org/D18200#inline-151433 This re-applies r266573 which I had reverted in r266576. Original review: http://reviews.llvm.org/D18875 llvm-svn: 266640
* [NFC] Header cleanupMehdi Amini2016-04-1836-56/+13
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* Revert "NFC: unify clang / LLVM atomic ordering"JF Bastien2016-04-171-7/+38
| | | | | | | | | | | | | | | | This reverts commit 537951f2f16d6a8542571c7722fcbae07d4e62c2. Causes an assert in: test/Transforms/AtomicExpand/SPARC/libcalls.ll (Ordering2 != AtomicOrdering::NotAtomic && "expect atomic MO") Bot: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/21724/testReport/junit/LLVM/Transforms_AtomicExpand_SPARC/libcalls_ll/ I'm not getting this assert on my local debug build, but I'll revert just to be sure. llvm-svn: 266576
* NFC: unify clang / LLVM atomic orderingJF Bastien2016-04-171-38/+7
| | | | | | | | | | | | Summary: This makes the C11 / C++11 *ABI* atomic ordering accessible from LLVM, as discussed in http://reviews.llvm.org/D18200#inline-151433 Reviewers: jyknight, reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18875 llvm-svn: 266573
* [ParallelCG] SmallVector<char> -> SmallString.Davide Italiano2016-04-171-2/+2
| | | | llvm-svn: 266568
* Keep only the splitCodegen version that takes a factory.Rafael Espindola2016-04-171-19/+0
| | | | | | | This makes it much easier to see that all created TargetMachines are equivalent. llvm-svn: 266564
OpenPOWER on IntegriCloud