summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG
Commit message (Collapse)AuthorAgeFilesLines
...
* Add an @llvm.sideeffect intrinsicDan Gohman2017-11-082-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements Chandler's idea [0] for supporting languages that require support for infinite loops with side effects, such as Rust, providing part of a solution to bug 965 [1]. Specifically, it adds an `llvm.sideeffect()` intrinsic, which has no actual effect, but which appears to optimization passes to have obscure side effects, such that they don't optimize away loops containing it. It also teaches several optimization passes to ignore this intrinsic, so that it doesn't significantly impact optimization in most cases. As discussed on llvm-dev [2], this patch is the first of two major parts. The second part, to change LLVM's semantics to have defined behavior on infinite loops by default, with a function attribute for opting into potential-undefined-behavior, will be implemented and posted for review in a separate patch. [0] http://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html [1] https://bugs.llvm.org/show_bug.cgi?id=965 [2] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118632.html Differential Revision: https://reviews.llvm.org/D38336 llvm-svn: 317729
* Handle inlined variables in SelectionDAGBuilder::EmitFuncArgumentDbgValue().Adrian Prantl2017-11-081-6/+0
| | | | | | | | | | | | | | | | | In 2010 a commit with no testcase and no further explanation explicitly disabled the handling of inlined variables in EmitFuncArgumentDbgValue(). I don't think there is a good reason for this any more and re-enabling this adds debug locations for variables associated with an LLVM function argument in functions that are inlined into the first basic block. The only downside of doing this is that we may insert a DBG_VALUE before the inlined scope, but (1) this could be filtered out later, and (2) LiveDebugValues will not propagate it into subsequent basic blocks if they don't dominate the variable's lexical scope, so this seems like a small price to pay. rdar://problem/26228128 llvm-svn: 317702
* DAG: Add computeKnownBitsForFrameIndexMatt Arsenault2017-11-082-5/+14
| | | | | | | | | | | | | Some of the AMDGPU stack addressing modes require knowing the sign bit is zero. We used to accomplish this by custom lowering frame indexes, and then putting an AssertZext around a TargetFrameIndex. This required specifically looking for the AssextZext + frame index pattern which was moderately disgusting. The same could probably be accomplished with a target specific node, but would still require special handling of frame indexes. llvm-svn: 317671
* Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layeringDavid Blaikie2017-11-0810-13/+13
| | | | | | | | This header includes CodeGen headers, and is not, itself, included by any Target headers, so move it into CodeGen to match the layering of its implementation. llvm-svn: 317647
* [SelectionDAG] Fix typo in comment. NFCCraig Topper2017-11-071-1/+1
| | | | llvm-svn: 317588
* Make DIExpression::createFragmentExpression() return an Optional.Adrian Prantl2017-11-072-8/+11
| | | | | | | We can't safely split arithmetic into multiple fragments because we can't express carry-over between fragments. llvm-svn: 317534
* [IR] redefine 'UnsafeAlgebra' / 'reassoc' fast-math-flags and add 'trans' ↵Sanjay Patel2017-11-061-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fast-math-flag As discussed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html and again more recently: http://lists.llvm.org/pipermail/llvm-dev/2017-October/118118.html ...this is a step in cleaning up our fast-math-flags implementation in IR to better match the capabilities of both clang's user-visible flags and the backend's flags for SDNode. As proposed in the above threads, we're replacing the 'UnsafeAlgebra' bit (which had the 'umbrella' meaning that all flags are set) with a new bit that only applies to algebraic reassociation - 'AllowReassoc'. We're also adding a bit to allow approximations for library functions called 'ApproxFunc' (this was initially proposed as 'libm' or similar). ...and we're out of bits. 7 bits ought to be enough for anyone, right? :) FWIW, I did look at getting this out of SubclassOptionalData via SubclassData (spacious 16-bits), but that's apparently already used for other purposes. Also, I don't think we can just add a field to FPMathOperator because Operator is not intended to be instantiated. We'll defer movement of FMF to another day. We keep the 'fast' keyword. I thought about removing that, but seeing IR like this: %f.fast = fadd reassoc nnan ninf nsz arcp contract afn float %op1, %op2 ...made me think we want to keep the shortcut synonym. Finally, this change is binary incompatible with existing IR as seen in the compatibility tests. This statement: "Newer releases can ignore features from older releases, but they cannot miscompile them. For example, if nsw is ever replaced with something else, dropping it would be a valid way to upgrade the IR." ( http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility ) ...provides the flexibility we want to make this change without requiring a new IR version. Ie, we're not loosening the FP strictness of existing IR. At worst, we will fail to optimize some previously 'fast' code because it's no longer recognized as 'fast'. This should get fixed as we audit/squash all of the uses of 'isFast()'. Note: an inter-dependent clang commit to use the new API name should closely follow commit. Differential Revision: https://reviews.llvm.org/D39304 llvm-svn: 317488
* Move TargetFrameLowering.h to CodeGen where it's implementedDavid Blaikie2017-11-033-3/+3
| | | | | | | | | | | This header already includes a CodeGen header and is implemented in lib/CodeGen, so move the header there to match. This fixes a link error with modular codegeneration builds - where a header and its implementation are circularly dependent and so need to be in the same library, not split between two like this. llvm-svn: 317379
* [X86] Fix bug in legalize vector types - Split large loadsAyman Musa2017-11-021-1/+1
| | | | | | | | | | When splitting a large load to smaller legally-typed loads, the last load should be padded to reach the size of the previous one so a CONCAT_VECTORS node could reunite them again. The code currently pads the last load to reach the size of the first load (instead of the previous). Differential Revision: https://reviews.llvm.org/D38495 Change-Id: Ib60b55ed26ce901fabf68108daf52683fbd5013f llvm-svn: 317206
* [SelectionDAG] computeKnownBits - use ashrInPlace on known bits of ISD::SRA ↵Simon Pilgrim2017-11-011-11/+3
| | | | | | input. NFCI. llvm-svn: 317087
* [DAGCombiner] Fix typos in comments. NFCCraig Topper2017-11-011-2/+2
| | | | llvm-svn: 317072
* Fix unused variable warnings. NFCI.Simon Pilgrim2017-10-301-3/+0
| | | | llvm-svn: 316964
* [SelectionDAG] Tidyup computeKnownBits extension/truncation cases. NFCI.Simon Pilgrim2017-10-301-17/+4
| | | | | | We don't need to extend/truncate the Known structure before calling computeKnownBits - it will reset at the start of the function. llvm-svn: 316962
* Create instruction classes for identifying any atomicity of memory ↵Daniel Neilson2017-10-301-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | intrinsic. (NFC) Summary: For reference, see: http://lists.llvm.org/pipermail/llvm-dev/2017-August/116589.html This patch fleshes out the instruction class hierarchy with respect to atomic and non-atomic memory intrinsics. With this change, the relevant part of the class hierarchy becomes: IntrinsicInst -> MemIntrinsicBase (methods-only class) -> MemIntrinsic (non-atomic intrinsics) -> MemSetInst -> MemTransferInst -> MemCpyInst -> MemMoveInst -> AtomicMemIntrinsic (atomic intrinsics) -> AtomicMemSetInst -> AtomicMemTransferInst -> AtomicMemCpyInst -> AtomicMemMoveInst -> AnyMemIntrinsic (both atomicities) -> AnyMemSetInst -> AnyMemTransferInst -> AnyMemCpyInst -> AnyMemMoveInst This involves some class renaming: ElementUnorderedAtomicMemCpyInst -> AtomicMemCpyInst ElementUnorderedAtomicMemMoveInst -> AtomicMemMoveInst ElementUnorderedAtomicMemSetInst -> AtomicMemSetInst A script for doing this renaming in downstream trees is included below. An example of where the Any* classes should be used in LLVM is when reasoning about the effects of an instruction (ex: aliasing). --- Script for renaming AtomicMem* classes: PREFIXES="[<,([:space:]]" CLASSES="MemIntrinsic|MemTransferInst|MemSetInst|MemMoveInst|MemCpyInst" SUFFIXES="[;)>,[:space:]]" REGEX="(${PREFIXES})ElementUnorderedAtomic(${CLASSES})(${SUFFIXES})" REGEX2="visitElementUnorderedAtomic(${CLASSES})" FILES=$( grep -E "(${REGEX}|${REGEX2})" -r . | tr ':' ' ' | awk '{print $1}' | sort | uniq ) SED_SCRIPT="s~${REGEX}~\1Atomic\2\3~g" SED_SCRIPT2="s~${REGEX2}~visitAtomic\1~g" for f in $FILES; do echo "Processing: $f" sed -i ".bak" -E "${SED_SCRIPT};${SED_SCRIPT2};${EA_SED_SCRIPT};${EA_SED_SCRIPT2}" $f done Reviewers: sanjoy, deadalnix, apilipenko, anna, skatkov, mkazantsev Reviewed By: sanjoy Subscribers: hfinkel, jholewinski, arsenm, sdardis, nhaehnle, JDevlieghere, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D38419 llvm-svn: 316950
* [SelectionDAG] Add VSELECT demanded elts support to computeKnownBits Simon Pilgrim2017-10-301-4/+4
| | | | llvm-svn: 316947
* [SelectionDAG] Add VSELECT support to computeKnownBits Simon Pilgrim2017-10-301-0/+1
| | | | llvm-svn: 316944
* [SelectionDAG] Add SELECT demanded elts support to ComputeNumSignBitsSimon Pilgrim2017-10-301-4/+5
| | | | llvm-svn: 316933
* [SelectionDAG] Add SEXT/AND/XOR/Or demanded elts support to ComputeNumSignBitsSimon Pilgrim2017-10-291-7/+11
| | | | llvm-svn: 316875
* [SelectionDAG] Add SRA/SHL demanded elts support to ComputeNumSignBitsSimon Pilgrim2017-10-291-3/+29
| | | | | | Introduce a isConstOrDemandedConstSplat helper function that can recognise a constant splat build vector for at least the demanded elts we care about. llvm-svn: 316866
* [SelectionDAG] Add support for INSERT_SUBVECTOR to computeKnownBitsSimon Pilgrim2017-10-281-0/+34
| | | | llvm-svn: 316847
* [SelectionDAG] Support 'bit preserving' floating points bitcasts on ↵Simon Pilgrim2017-10-281-7/+15
| | | | | | | | | | | | computeKnownBits/ComputeNumSignBits For cases where we know the floating point representations match the bitcasted integer equivalent, allow bitcasting to these types. This is especially useful for the X86 floating point compare results which return all/zero bits but as a floating point type. Differential Revision: https://reviews.llvm.org/D39289 llvm-svn: 316831
* [DAGCombine] Don't combine sext with extload if sextload is not supported ↵Guozhi Wei2017-10-271-1/+5
| | | | | | | | | | | | | | | and extload has multi users In function DAGCombiner::visitSIGN_EXTEND_INREG, sext can be combined with extload even if sextload is not supported by target, then if sext is the only user of extload, there is no big difference, no harm no benefit. if extload has more than one user, the combined sextload may block extload from combining with other zext, causes extra zext instructions generated. As demonstrated by the attached test case. This patch add the constraint that when sextload is not supported by target, sext can only be combined with extload if it is the only user of extload. Differential Revision: https://reviews.llvm.org/D39108 llvm-svn: 316802
* DAG: Fold fma (fneg x), K, y -> fma x, -K, yMatt Arsenault2017-10-271-0/+8
| | | | llvm-svn: 316753
* Add subclass data to the FoldingSetNode for MemIntrinsicSDNodes.Sean Fertile2017-10-271-0/+2
| | | | | | | | | | | Not having the subclass data on an MemIntrinsicSDNodes means it was possible to try to fold 2 nodes with the same operands but differing MMO flags. This would trip an assertion when trying to refine the alignment between the 2 MachineMemOperands. Differential Revision: https://reviews.llvm.org/D38898 llvm-svn: 316737
* DAG: Fix creating select with wrong condition typeMatt Arsenault2017-10-251-1/+10
| | | | | | | | | | | | | | | | | | | This code added in r297930 assumed that it could create a select with a condition type that is just an integer bitcast of the selected type. For AMDGPU any vselect is going to be scalarized (although the vector types are legal), and all select conditions must be i1 (the same as getSetCCResultType). This logic doesn't really make sense to me, but there's never really been a consistent policy in what the select condition mask type is supposed to be. Try to extend the logic for skipping the transform for condition types that aren't setccs. It doesn't seem quite right to me though, but checking conditions that seem more sensible (like whether the vselect is going to be expanded) doesn't work since this seems to depend on that also. llvm-svn: 316554
* Implement salavageDebugInfo functionality for SelectionDAG.Adrian Prantl2017-10-242-0/+35
| | | | | | | | | | | | | | Similar to how llvm::salvagDebugInfo hooks into InstCombine, this adds a hook that can be invoked before an SDNode that is associated with an SDDbgValue is erased to capture the effect of the deleted node in a DIExpression. The motivating example is an SDDebugValue attached to an ADD operation that gets folded into a LOAD+OFFSET operation. rdar://problem/32121503 llvm-svn: 316525
* Use range-based for loop. NFCAdrian Prantl2017-10-241-5/+2
| | | | llvm-svn: 316496
* Use range-based-for. NFCAdrian Prantl2017-10-241-6/+5
| | | | llvm-svn: 316485
* Doxygenify comments.Adrian Prantl2017-10-241-26/+25
| | | | llvm-svn: 316466
* [SelectionDAG] Add VSELECT support to ComputeNumSignBitsSimon Pilgrim2017-10-241-0/+1
| | | | llvm-svn: 316457
* Fix buildbot breakageGeorge Burgess IV2017-10-231-0/+1
| | | | | | SP is only used in an assert. Caused by r316374. llvm-svn: 316377
* Don't crash when we see unallocatable registers in clobbersGeorge Burgess IV2017-10-233-15/+34
| | | | | | | | | | | | | | This fixes a bug where we'd crash given code like the test-case from https://bugs.llvm.org/show_bug.cgi?id=30792 . Instead, we let the offending clobber silently slide through. This doesn't fully fix said bug, since the assembler will still complain the moment it sees a crypto/fp/vector op, and we still don't diagnose calls that require vector regs. Differential Revision: https://reviews.llvm.org/D39030 llvm-svn: 316374
* [DAGCombine] Permit combining of shuffles of equivalent splat BUILD_VECTORsSimon Pilgrim2017-10-231-5/+15
| | | | | | | | | | combineShuffleOfScalars is very conservative about shuffled BUILD_VECTORs that can be combined together. This patch adds one additional case - if both BUILD_VECTORs represent splats of the same scalar value but with different UNDEF elements, then we should create a single splat BUILD_VECTOR, sharing only the UNDEF elements defined by the shuffle mask. Differential Revision: https://reviews.llvm.org/D38696 llvm-svn: 316331
* [SelectionDAG] Use dyn_cast without cast.Florian Hahn2017-10-211-2/+2
| | | | llvm-svn: 316258
* [SelectionDAG] Use isa to silence unused variable warning (NFC).Florian Hahn2017-10-211-1/+1
| | | | llvm-svn: 316257
* [SelectionDAG] Don't subject ConstantSDNodes to the depth limit in ↵Craig Topper2017-10-211-10/+13
| | | | | | | | computeKnownBits and ComputeNumSignBits. We don't need to do any additional recursion, we just need to analyze the APInt stored in the node. This matches what the ValueTracking versions do for IR. llvm-svn: 316256
* [SelectionDAG] Don't subject ISD:Constant to the depth limit in ↵Craig Topper2017-10-211-5/+7
| | | | | | | | | | | | | | | | | | | TargetLowering::SimplifyDemandedBits. Summary: We shouldn't recurse any further but it doesn't mean we shouldn't be able to give the known bits for a constant. The caller would probably like that we always return the right answer for a constant RHS. This matches what InstCombine does in this case. I don't have a test case because this showed up while trying to revive D31724. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: arsenm, llvm-commits Differential Revision: https://reviews.llvm.org/D38967 llvm-svn: 316255
* [SelectionDAG] Add a check to getVectorShuffle to ensure that the only ↵Craig Topper2017-10-191-1/+2
| | | | | | negative index we allow is -1. llvm-svn: 316183
* Untabify.NAKAMURA Takumi2017-10-181-1/+1
| | | | llvm-svn: 316079
* [DAGCombine] Add SCALAR_TO_VECTOR undef handling to simplifyShuffleMask.Simon Pilgrim2017-10-171-2/+6
| | | | | | | | This allows us to simplify later visitVECTOR_SHUFFLE optimizations such as combineShuffleOfScalars. Noticed whilst working on D38696 llvm-svn: 316017
* Use the return value of UpdateNodeOperands(); in some cases, ↵Mark Searles2017-10-161-1/+1
| | | | | | | | UpdateNodeOperands() modifies the node in-place and using the return value isn’t strictly necessary. However, it does not necessarily modify the node, but may return a resultant node if it already exists in the DAG. See comments in UpdateNodeOperands(). In that case, the return value must be used to avoid such scenarios as an infinite loop (node is assumed to have been updated, so added back to the worklist, and re-processed; however, node hasn’t changed so it is once again passed to UpdateNodeOperands(), assumed modified, added back to worklist; cycle infinitely repeats). Differential Revision: https://reviews.llvm.org/D38466 llvm-svn: 315957
* Add iterator range MachineRegisterInfo::liveins(), adopt users, NFCKrzysztof Parzyszek2017-10-161-4/+3
| | | | llvm-svn: 315927
* ISel type legalizer: debug messages. NFC.Sjoerd Meijer2017-10-162-4/+17
| | | | | | | | | | | Minor addition and follow up of r314773 and r311533: this adds more debug messages to the type legalizer. For each node, it dumps legalization info for results and operands nodes, rather than just the final legalized node. Differential Revision: https://reviews.llvm.org/D38726 llvm-svn: 315904
* Reverting r315590; it did not include changes for llvm-tblgen, which is ↵Aaron Ballman2017-10-153-8/+8
| | | | | | | | causing link errors for several people. Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1 llvm-svn: 315854
* DAG: Add opcode and source type to isFPExtFreeMatt Arsenault2017-10-131-235/+253
| | | | | | | | This is only currently used for mad/fma transforms. This is the only case where it should be used for AMDGPU, so add an opcode to be sure. llvm-svn: 315740
* DAG: Add flags to dumpsMatt Arsenault2017-10-131-0/+30
| | | | llvm-svn: 315690
* [SelectionDAG] Cleanup the SIGN_EXTEND_INREG handling in computeKnownBits. NFCICraig Topper2017-10-131-26/+14
| | | | | | Use less temporary APInts. Use bit counting more. Don't call getScalarSizeInBits so many places, just capture it once. llvm-svn: 315671
* [SelectionDAG] Fix typo in comment. NFCCraig Topper2017-10-131-1/+1
| | | | llvm-svn: 315670
* [SelectionDAG] Correct the early out in SelectionDAG::getZeroExtendInReg to ↵Craig Topper2017-10-131-1/+1
| | | | | | | | work properly for vector types. I don't know if we ever hit this case or not. Turning it into an assert only fired on expanding some atomic operation in a SystemZ lit test. llvm-svn: 315648
* [SelectionDAG] Const-correct the DemandedMask argument to one of the ↵Craig Topper2017-10-121-1/+1
| | | | | | overloads of SimplifyDemandedBits. NFC llvm-svn: 315641
OpenPOWER on IntegriCloud