summaryrefslogtreecommitdiff
path: root/llvm/lib/Transforms/Utils/ScalarEvolutionExpander.cpp
AgeCommit message (Collapse)Author
2025-06-17[DebugInfo][RemoveDIs] Remove a swathe of debug-intrinsic code (#144389)Jeremy Morse
Seeing how we can't generate any debug intrinsics any more: delete a variety of codepaths where they're handled. For the most part these are plain deletions, in others I've tweaked comments to remain coherent, or added a type to (what was) type-generic-lambdas. This isn't all the DbgInfoIntrinsic call sites but it's most of the simple scenarios. Co-authored-by: Nikita Popov <github@npopov.com>
2025-06-10[NFC][LLVM] Refactor IRBuilder::Create{VScale,ElementCount,TypeSize}. (#142803)Paul Walker
CreateVScale took a scaling parameter that had a single use outside of IRBuilder with all other callers having to create a redundant ConstantInt. To work round this some code perferred to use CreateIntrinsic directly. This patch simplifies CreateVScale to return a call to the llvm.vscale() intrinsic and nothing more. As well as simplifying the existing call sites I've also migrated the uses of CreateIntrinsic. Whilst IRBuilder used CreateVScale's scaling parameter as part of the implementations of CreateElementCount and CreateTypeSize, I have follow-on work to switch them to the NUW varaiety and thus they would stop using CreateVScale's scaling as well. To prepare for this I have moved the multiplication and constant folding into the implementations of CreateElementCount and CreateTypeSize. As a final step I have replaced some callers of CreateVScale with CreateElementCount where it's clear from the code they wanted the latter.
2025-05-26[llvm] Value-initialize values with *Map::try_emplace (NFC) (#141522)Kazu Hirata
try_emplace value-initializes values, so we do not need to pass nullptr to try_emplace when the value types are raw pointers or std::unique_ptr<T>.
2025-04-19[Utils] Avoid repeated hash lookups (NFC) (#136414)Kazu Hirata
2025-04-18[Transforms] Construct SmallVector with iterator ranges (NFC) (#136259)Kazu Hirata
2025-04-13SCEVExpander: Don't look at uses of constants (#134691)Matt Arsenault
This could be more relaxed, and look for uses of globals in the same function but no tests apparently depend on that.
2025-03-27[Transforms] Use range constructors of *Set (NFC) (#133203)Kazu Hirata
2025-02-11[VPlan] Only skip expansion for SCEVUnknown if it isn't an instruction. ↵Florian Hahn
(#125235) Update getOrCreateVPValueForSCEVExpr to only skip expansion of SCEVUnknown if the underlying value isn't an instruction. Instructions may be defined in a loop and using them without expansion may break LCSSA form. SCEVExpander will take care of preserving LCSSA if needed. We could also try to pass LoopInfo, but there are some users of the function where it won't be available and main benefit from skipping expansion is slightly more concise VPlans. Note that SCEVExpander is now used to expand SCEVUnknown with floats. Adjust the check in expandCodeFor to only check the types and casts if the type of the value is different to the requested type. Otherwise we crash when trying to expand a float and requesting a float type. Fixes https://github.com/llvm/llvm-project/issues/121518. PR: https://github.com/llvm/llvm-project/pull/125235
2025-01-24[NFC][DebugInfo] Use iterator moveBefore at many call-sites (#123583)Jeremy Morse
As part of the "RemoveDIs" project, BasicBlock::iterator now carries a debug-info bit that's needed when getFirstNonPHI and similar feed into instruction insertion positions. Call-sites where that's necessary were updated a year ago; but to ensure some type safety however, we'd like to have all calls to moveBefore use iterators. This patch adds a (guaranteed dereferenceable) iterator-taking moveBefore, and changes a bunch of call-sites where it's obviously safe to change to use it by just calling getIterator() on an instruction pointer. A follow-up patch will contain less-obviously-safe changes. We'll eventually deprecate and remove the instruction-pointer insertBefore, but not before adding concise documentation of what considerations are needed (very few).
2024-12-13PatternMatch: migrate to CmpPredicate (#118534)Ramkumar Ramachandra
With the introduction of CmpPredicate in 51a895a (IR: introduce struct with CmpInst::Predicate and samesign), PatternMatch is one of the first key pieces of infrastructure that must be updated to match a CmpInst respecting samesign information. Implement this change to Cmp-matchers. This is a preparatory step in migrating the codebase over to CmpPredicate. Since we no functional changes are desired at this stage, we have chosen not to migrate CmpPredicate::operator==(CmpPredicate) calls to use CmpPredicate::getMatching(), as that would have visible impact on tests that are not yet written: instead, we call CmpPredicate::operator==(Predicate), preserving the old behavior, while also inserting a few FIXME comments for follow-ups.
2024-11-11[SCEVExpander] Don't try to reuse SCEVUnknown values (#115141)Nikita Popov
The expansion of a SCEVUnknown is trivial (it's just the wrapped value). If we try to reuse an existing value it might be a more complex expression that simplifies to the SCEVUnknown. This is inspired by https://github.com/llvm/llvm-project/issues/114879, because SCEVExpander replacing a constant with a phi node is just silly. (I don't consider this a fix for that issue though.)
2024-10-17[SCEVExpander] Expand UDiv avoiding UB when in seq_min/max. (#92177)Florian Hahn
Update SCEVExpander to introduce an SafeUDivMode, which is set when expanding operands of SCEVSequentialMinMaxExpr. In this mode, the expander will make sure that the divisor of the expanded UDiv is neither 0 nor poison. Fixes https://github.com/llvm/llvm-project/issues/89958. PR https://github.com/llvm/llvm-project/pull/92177
2024-10-17[LLVM] Make more use of IRBuilder::CreateIntrinsic. NFC. (#112706)Jay Foad
Convert many instances of: Fn = Intrinsic::getOrInsertDeclaration(...); CreateCall(Fn, ...) to the equivalent CreateIntrinsic call.
2024-10-15[IR] Add `samesign` flag to icmp instruction (#111419)elhewaty
Inspired by https://discourse.llvm.org/t/rfc-signedness-independent-icmps/81423
2024-10-11[NFC] Rename `Intrinsic::getDeclaration` to `getOrInsertDeclaration` (#111752)Rahul Joshi
Rename the function to reflect its correct behavior and to be consistent with `Module::getOrInsertFunction`. This is also in preparation of adding a new `Intrinsic::getDeclaration` that will have behavior similar to `Module::getFunction` (i.e, just lookup, no creation).
2024-10-03Fix LLVM_ENABLE_ABI_BREAKING_CHECKS macro check: use #if instead of #ifdef ↵Mehdi Amini
(#110938) This macros is always defined: either 0 or 1. The correct pattern is to use #if. Re-apply #110185 with more fixes for debug build with the ABI breaking checks disabled.
2024-10-02Revert "Fix LLVM_ENABLE_ABI_BREAKING_CHECKS macro check: use #if inst… ↵Christopher Di Bella
(#110923) …ead of #ifdef (#110883)" This reverts commit 1905cdbf4ef15565504036c52725cb0622ee64ef, which causes lots of failures where LLVM doesn't have the right header guards. The errors can be seen on [BuildKite](https://buildkite.com/llvm-project/upstream-bazel/builds/112362#01924eae-231c-4d06-ba87-2c538cf40e04), where the source uses `#ifndef NDEBUG`, but the content in question is defined when `LLVM_ENABLE_ABI_BREAKING_CHECKS == 1`. For example, `llvm/include/llvm/Support/GenericDomTreeConstruction.h` has the following: ```cpp // Helper struct used during edge insertions. struct InsertionInfo { // ... #ifdef LLVM_ENABLE_ABI_BREAKING_CHECKS SmallVector<TreeNodePtr, 8> VisitedUnaffected; #endif }; // ... InsertionInfo II; // ... #ifndef NDEBUG II.VisitedUnaffected.push_back(SuccTN); #endif ```
2024-10-02Fix LLVM_ENABLE_ABI_BREAKING_CHECKS macro check: use #if instead of #ifdef ↵Mehdi Amini
(#110883) This macros is always defined: either 0 or 1. The correct pattern is to use #if. Reapply https://github.com/llvm/llvm-project/pull/110185 with fixes.
2024-10-02[SCEVExpander] Preserve gep nuw during expansion (#102133)Nikita Popov
When expanding SCEV adds to geps, transfer the nuw flag to the resulting gep. (Note that this doesn't apply to IV increment GEPs, which go through a different code path.)
2024-10-01[SCEVExpander] Clear flags when reusing GEP (#109293)Nikita Popov
As pointed out in the review of #102133, SCEVExpander currently incorrectly reuses GEP instructions that have poison-generating flags set. Fix this by clearing the flags on the reused instruction.
2024-09-27Revert "Fix LLVM_ENABLE_ABI_BREAKING_CHECKS macro check: use #if instead of ↵Mehdi Amini
#ifdef" (#110310) Reverts llvm/llvm-project#110185 There are inconsistencies in some of these macros, which unfortunately isn't caught by a single upstream bot.
2024-09-27Fix LLVM_ENABLE_ABI_BREAKING_CHECKS macro check: use #if instead of #ifdef ↵Mehdi Amini
(#110185) This macros is always defined: either 0 or 1. The correct pattern is to use #if.
2024-09-19[SCEVExpander] Fix addrec cost model (#106704)Nikita Popov
The current isHighCostExpansion cost model for addrecs computes the cost for some kind of polynomial expansion that does not appear to have any relation to addrec expansion whatsoever. A literal expansion of an affine addrec is a phi and add (plus the expansion of start and step). For a non-affine addrec, we get another phi+add for each additional addrec nested in the step recurrence. This partially `fixes` https://github.com/llvm/llvm-project/issues/53205 (the runtime unroll test case in this PR).
2024-06-24Revert "[IR][NFC] Update IRBuilder to use InsertPosition (#96497)"Stephen Tozer
Reverts the above commit, as it updates a common header function and did not update all callsites: https://lab.llvm.org/buildbot/#/builders/29/builds/382 This reverts commit 6481dc57612671ebe77fe9c34214fba94e1b3b27.
2024-06-24[IR][NFC] Update IRBuilder to use InsertPosition (#96497)Stephen Tozer
Uses the new InsertPosition class (added in #94226) to simplify some of the IRBuilder interface, and removes the need to pass a BasicBlock alongside a BasicBlock::iterator, using the fact that we can now get the parent basic block from the iterator even if it points to the sentinel. This patch removes the BasicBlock argument from each constructor or call to setInsertPoint. This has no functional effect, but later on as we look to remove the `Instruction *InsertBefore` argument from instruction-creation (discussed [here](https://discourse.llvm.org/t/psa-instruction-constructors-changing-to-iterator-only-insertion/77845)), this will simplify the process by allowing us to deprecate the InsertPosition constructor directly and catch all the cases where we use instructions rather than iterators.
2024-06-19[SCEVExpander] Recognize urem idiom during expansion (#96005)Philip Reames
If we have a urem expression, emitting it as a urem is significantly better that letting the fully expansion kick in. We have the risk of a udiv or mul which could have previously been shared, but loosing that seems like a reasonable tradeoff for being able to round trip a urem w/o modification.
2024-06-10Revert 291b415c6c39156c82c7cdefd7a6a67657fb6927 : [Misc] Use ↵Simon Pilgrim
`LLVM_ENABLE_ABI_BREAKING_CHECKS` correctly (#94212) The patch didn't consistently clean up `#ifdef LLVM_ENABLE_ABI_BREAKING_CHECKS` and '#if defined(LLVM_ENABLE_ABI_BREAKING_CHECKS)' paths, causing a lot of build failures
2024-06-10[Misc] Use `LLVM_ENABLE_ABI_BREAKING_CHECKS` correctly (#94212)paperchalice
`LLVM_ENABLE_ABI_BREAKING_CHECKS` is always defined: https://github.com/llvm/llvm-project/blob/72c901f5e59477e568b1b04dae9de753b9d1f6f3/llvm/include/llvm/Config/abi-breaking.h.cmake#L16C2-L16C15 It uses `cmakedefine01` rather than `cmakedefine`, so `LLVM_ENABLE_ABI_BREAKING_CHECKS` is always defined, so the preprocessed code is probably not what the author wanted.
2024-06-04[LAA] Use PSE::getSymbolicMaxBackedgeTakenCount. (#93499)Florian Hahn
Update LAA to use PSE::getSymbolicMaxBackedgeTakenCount which returns the minimum of the countable exits. When analyzing dependences and computing runtime checks, we need the smallest upper bound on the number of iterations. In terms of memory safety, it shouldn't matter if any uncomputable exits leave the loop, as long as we prove that there are no dependences given the minimum of the countable exits. The same should apply also for generating runtime checks. Note that this shifts the responsiblity of checking whether all exit counts are computable or handling early-exits to the users of LAA. Depends on https://github.com/llvm/llvm-project/pull/93498 PR: https://github.com/llvm/llvm-project/pull/93499
2024-04-18[IR] Drop poison-generating return attributes when necessary (#89138)Andreas Jonson
Rename has/dropPoisonGeneratingFlagsOrMetadata to has/dropPoisonGeneratingAnnotations and make it also handle nonnull, align and range return attributes on calls, similar to the existing handling for !nonnull, !align and !range metadata.
2024-03-29[IR] Add nowrap flags for trunc instruction (#85592)elhewaty
This patch adds the nuw (no unsigned wrap) and nsw (no signed wrap) poison-generating flags to the trunc instruction. Discourse thread: https://discourse.llvm.org/t/rfc-add-nowrap-flags-to-trunc/77453
2024-03-04[RemoveDIs] Reapply 3fda50d3915, insert instructions using iteratorsJeremy Morse
I'd reverted this in 6c7805d5d1 after a bad stage. Original commit messsage follows: [NFC][RemoveDIs] Bulk update utilities to insert with iterators As part of the RemoveDIs project we need LLVM to insert instructions using iterators wherever possible, so that the iterators can carry a bit of debug-info. This commit implements some of that by updating the contents of llvm/lib/Transforms/Utils to always use iterator-versions of instruction constructors. There are two general flavours of update: * Almost all call-sites just call getIterator on an instruction * Several make use of an existing iterator (scenarios where the code is actually significant for debug-info) The underlying logic is that any call to getFirstInsertionPt or similar APIs that identify the start of a block need to have that iterator passed directly to the insertion function, without being converted to a bare Instruction pointer along the way. I've also switched DemotePHIToStack to take an optional iterator: it needs to take an iterator, and having a no-insert-location behaviour appears to be important. The constructors for ICmpInst and FCmpInst have been updated too. They're the only instructions that take block _references_ rather than pointers for certain calls, and a future patch is going to make use of default-null block insertion locations. All of this should be NFC.
2024-02-29Revert "[NFC][RemoveDIs] Bulk update utilities to insert with iterators"Jeremy Morse
This reverts commit 3fda50d3915b2163a54a37b602be7783a89dd808. Apparently I've missed a hunk while staging this; will back out for now. Picked up here: https://lab.llvm.org/buildbot/#/builders/139/builds/60429/steps/6/logs/stdio
2024-02-29[NFC][RemoveDIs] Bulk update utilities to insert with iteratorsJeremy Morse
As part of the RemoveDIs project we need LLVM to insert instructions using iterators wherever possible, so that the iterators can carry a bit of debug-info. This commit implements some of that by updating the contents of llvm/lib/Transforms/Utils to always use iterator-versions of instruction constructors. There are two general flavours of update: * Almost all call-sites just call getIterator on an instruction * Several make use of an existing iterator (scenarios where the code is actually significant for debug-info) The underlying logic is that any call to getFirstInsertionPt or similar APIs that identify the start of a block need to have that iterator passed directly to the insertion function, without being converted to a bare Instruction pointer along the way. I've also switched DemotePHIToStack to take an optional iterator: it needs to take an iterator, and having a no-insert-location behaviour appears to be important. The constructors for ICmpInst and FCmpInst have been updated too. They're the only instructions that take block _references_ rather than pointers for certain calls, and a future patch is going to make use of default-null block insertion locations. All of this should be NFC.
2024-02-21[LIR][SCEVExpander] Restore original flags when aborting transform (#82362)Nikita Popov
SCEVExpanderCleaner will currently remove instructions created by SCEVExpander, but not restore poison generating flags that it may have dropped. As such, running LIR can currently spuriously drop flags without performing any transforms. Fix this by keeping track of original instruction flags in SCEVExpander. Fixes https://github.com/llvm/llvm-project/issues/82337.
2024-02-20[IndVars] Recompute flags if needed in widenIVUse of IV increment. (#82352)Florian Hahn
widenIVUse may hoist a wide induction increment and introduce new uses, but does not recompute the wrap flags. In some cases this can make the new uses of the wide IV inc more poisonous. Update the code to recompute flags if needed when hoisting an IV. If both the narrow and wide IV increment's flags match and we can re-use the flags from the increments, there's no need to recompute the flags, as the replacement won't make the new uses of the wide IV's increment more poisonous. Note that this also updates a stale comment which claimed that the widen increment is only used if it dominates the new use. The helper should also be used to guard the code added in da437330be, which I am planning on doing separately once the helper lands. Fixes https://github.com/llvm/llvm-project/issues/82243.
2024-02-07[SCEVExpander] Don't use recursive expansion for ptr IV incNikita Popov
Similar to the non-ptr case, directly create the getelementptr instruction. Going through expandAddToGEP() no longer makes sense with opaque pointers, where generating the necessary instruction is trivial. This avoids recursive expansion of (the SCEV of) StepV while the IR is in an inconsistent state, in particular with an incomplete IV phi node, which utilities may not be prepared to deal with. Fixes https://github.com/llvm/llvm-project/issues/80954.
2024-02-02[SCEV] Move canReuseInstruction() helper into SCEV (NFC)Nikita Popov
To allow reusing it in IndVars.
2024-02-02[SCEVExpander] Do not reuse disjoint or (#80281)Nikita Popov
SCEV treats "or disjoint" the same as "add nsw nuw". However, when expanding, we cannot generally replace an add SCEV node with an "or disjoint" instruction. Just dropping the poison flag is insufficient in this case, we would have to actually convert the or into an add. This is a partial fix for #79861.
2024-02-01[SCEVExp] Keep NUW/NSW if both original inc and isomporphic inc agree. (#79512)Florian Hahn
We are replacing with a wider increment. If both OrigInc and IsomorphicInc are NUW/NSW, then we can preserve them on the wider increment; the narrower IsomorphicInc would wrap before the wider OrigInc, so the replacement won't make IsomorphicInc's uses more poisonous. PR: https://github.com/llvm/llvm-project/pull/79512
2024-01-25[Transforms] Use llvm::pred_size and llvm::pred_successors (NFC)Kazu Hirata
2024-01-25[SCEVExp] Move logic to replace congruent IV increments to helper (NFC).Florian Hahn
Move logic to replace congruent IV increments to helper function, to reduce the indentation by using early returns. This is in preparation for a follow-up patch.
2024-01-12[IRBuilder] Add CreatePtrAdd() method (NFC) (#77582)Nikita Popov
This abstracts over the common pattern of creating a gep with i8 element type.
2023-12-07[SCEVExpander] Attempt to reinfer flags dropped due to CSE (#72431)Philip Reames
LSR uses SCEVExpander to generate induction formulas. The expander internally tries to reuse existing IR expressions. To do that, it needs to strip any poison generating flags (nsw, nuw, exact, nneg, etc..) which may not be valid for the newly added users. This is conservatively correct, but has the effect that LSR will strip nneg flags on zext instructions involved in trip counts in loop preheaders. To avoid this, this patch adjusts the expanded to reinfer the flags on the CSE candidate if legal for all possible users. This should fix the regression reported in https://github.com/llvm/llvm-project/issues/71200. This should arguably be done inside canReuseInstruction instead, but doing it outside is more conservative compile time wise. Both canReuseInstruction and isGuaranteedNotToBePoison walk operand lists, so right now we are performing work which is roughly O(N^2) in the size of the operand graph. We should fix that before making the per operand step more expensive. My tenative plan is to land this, and then rework the code to sink the logic into more core interfaces.
2023-11-10[IRBuilder] Add IsNonNeg param to CreateZExt() (NFC)Nikita Popov
2023-10-31[SCEV] Teach SCEVExpander to use zext nneg when possible (#70815)Philip Reames
zext nneg was recently added to the IR in #67982. Teaching SCEVExpander to emit nneg when possible is valuable since SCEV may have proved non-trivial facts about loop bounds which would otherwise be lost when materializing the value.
2023-09-29[SCEVExpander] Remove unused variable [NFC]Mikael Holmen
gcc warned about it: ../lib/Transforms/Utils/ScalarEvolutionExpander.cpp: In lambda function: ../lib/Transforms/Utils/ScalarEvolutionExpander.cpp:2104:22: warning: unused variable 'ARPtrTy' [-Wunused-variable] 2104 | if (PointerType *ARPtrTy = dyn_cast<PointerType>(ARTy)) { | ^~~~~~~ Fix the warning by removing the variable and turn dyn_cast into isa.
2023-09-22[SCEVExpander] Clarify absence of no-op casts (NFC)Nikita Popov
Remove all the expandCodeFor() uses that specify an explicit type, as well as InsertNoopCastOfTo() calls and most uses of getEffectiveSCEVType(). The only place where no-op casts can now be inserted are public expandCodeFor() uses.
2023-09-22[SCEV] Fix -Wunused-variable in ScalarEvolutionExpander.cpp (NFC)Jie Fu
llvm-project/llvm/lib/Transforms/Utils/ScalarEvolutionExpander.cpp:1077:15: error: unused variable 'Start' [-Werror,-Wunused-variable] const SCEV *Start = Normalized->getStart(); ^ 1 error generated.
2023-09-22[SCEV] Require that addrec operands dominate the loopNikita Popov
SCEVExpander currently has special handling for the case where the start or the step of an addrec do not dominate the loop header, which is not used by any lit test. Initially I thought that this is entirely dead code, because addrec operands are required to be loop invariant. However, SCEV currently allows creating an addrec with operands that are loop invariant but defined *after* the loop. This doesn't seem like a useful case to allow, and we don't appear to be using this outside a single easy to adjust unit test.