search for: getaddexpr

...ks there as well. > > diff --git a/lib/Analysis/ScalarEvolution.cpp > b/lib/Analysis/ScalarEvolution.cpp > index 39ced1e..2e87902 100644 > --- a/lib/Analysis/ScalarEvolution.cpp > +++ b/lib/Analysis/ScalarEvolution.cpp > @@ -2274,19 +2274,19 @@ const SCEV > *ScalarEvolution::getAddExpr(SmallVectorImpl<const SCEV *> &Ops, > } > > // If we found some loop invariants, fold them into the recurrence. > if (!LIOps.empty()) { > // NLI + LI + {Start,+,Step} --> NLI + {LI+Start,+,Step} > LIOps.push_back(AddRec->getStart()...

​Hi, Would you be able to kindly check and assist with the IndVarSimplify / SCEV problem I got in the latest LLVM, please? Sometimes IndVarSimplify may not eliminate narrow IV's when there actually exists such a possibility. This may affect other LLVM passes and result in inefficient code. The reproducing test 'indvar_test.cpp' is attached. The problem is with the second

...oblem properly, we need to fully understand why that assumption about dominance is there and the implications of removing it. It would be good if you could be more specific about your idea of nullptr or SCEV_unknown (eg which function would return those values and when), but returning nullptr from getAddExpr or getSCEVAtScope may be problematic since they currently return valid pointers all the time and changing that would be error prone and would increase code complexity. Returning SCEV_Unknown from getAddExpr would seem plausible except that it would not allow for expression simplifications where rec...

I'd like a value, call it Bottom, such that SE->getAddExpr(Bottom, X) => Bottom SE->getMulExpr(Bottom, X,) => Bottom isKnownPredicate(any, Bottom, X) => false etc. I can write code to make NULL work like I want, but it would be simpler if something was already defined. I'm wondering about SCEV::Unknown. The documentation suggests I could...

...ames.com>, "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org> Date: 2020/04/16 04:34 PM Subject: [EXTERNAL] RE: [llvm-dev] Scalar Evolution Expressions Involving Sibling Loops Hi Bardia, I am encountering a similar problem and totally agree that getAddExpr shouldn’t generate any assertion error or at least provide condition check. Even if this is something to avoid, would it be better to return nullptr instead of assertion error? Thanks, Jimmy From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Bardia Mahjour via llvm-dev Sent:...

On Sun, 7 Oct 2012 18:53:59 -0700 Preston Briggs <preston.briggs at gmail.com> wrote: > I'd like a value, call it Bottom, such that > > SE->getAddExpr(Bottom, X) => Bottom > SE->getMulExpr(Bottom, X,) => Bottom > isKnownPredicate(any, Bottom, X) => false > etc. > > > I can write code to make NULL work like I want, but it would be > simpler if something was already defined. I'm wondering about > SCEV::Unkn...

...The actual crash and the back-trace: ---------------------------------------------------------------------------------------------------------------------------------------------------------- opt: $SRC/llvm-project/llvm/lib/Analysis/ScalarEvolution.cpp:2165: const llvm::SCEV *llvm::ScalarEvolution::getAddExpr(SmallVectorImpl<const llvm::SCEV *> &, SCEV::NoWrapFlags, unsigned int): Assertion `getEffectiveSCEVType(Ops[i]->getType()) == ETy && "SCEVAddExpr operand types don't match!"' failed. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash b...

...al -print-no-aliases ptr_test.O1.ll` The core dump message is also in the attachments. Investigations 1. SCEV-AA try to ‘minus' the SCEV expressions of the given two pointers(lib/Analysis/ScalarEvolutionAliasAnalysis.cpp:64) 2. ScalarEvolution::getMinusSCEV will boil down into ScalarEvolution::getAddExpr. On line 2383 of lib/Analysis/ScalarEvolution.cpp, GroupByComplexity is invoked. 3. CompareSCEVComplexity is eventually called to give a partial order between two SCEV expression. 4. If there are two SCEVAddExpr that are located in different loops which don’t have any hierarchical relation, just li...

...ggs at gmail.com > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] SCEV bottom value > > On Sun, 7 Oct 2012 18:53:59 -0700 > Preston Briggs <preston.briggs at gmail.com> wrote: > > > I'd like a value, call it Bottom, such that > > > > SE->getAddExpr(Bottom, X) => Bottom > > SE->getMulExpr(Bottom, X,) => Bottom > > isKnownPredicate(any, Bottom, X) => false > > etc. > > > > > > I can write code to make NULL work like I want, but it would be > > simpler if something was already defined. I'...

...The actual crash and the back-trace: ---------------------------------------------------------------------------------------------------------------------------------------------------------- opt: $SRC/llvm-project/llvm/lib/Analysis/ScalarEvolution.cpp:2165: const llvm::SCEV *llvm::ScalarEvolution::getAddExpr(SmallVectorImpl<const llvm::SCEV *> &, SCEV::NoWrapFlags, unsigned int): Assertion `getEffectiveSCEVType(Ops[i]->getType()) == ETy && "SCEVAddExpr operand types don't match!"' failed. PLEASE submit a bug report to https://bugs.llvm.org/<https://nam11.safeli...

.... diff --git a/lib/Analysis/ScalarEvolution.cpp b/lib/Analysis/ScalarEvolution.cpp index 7bc848a..5ce4fd2 100644 --- a/lib/Analysis/ScalarEvolution.cpp +++ b/lib/Analysis/ScalarEvolution.cpp @@ -2770,6 +2770,17 @@ const SCEV *ScalarEvolution::getMinusSCEV(const SCEV *LHS, const SCEV *RHS, return getAddExpr(LHS, getNegativeSCEV(RHS), Flags); } +const SCEV * +ScalarEvolution::getTruncateAndZeroExtend(const SCEV *V, Type *Ty) { + Type *SrcTy = V->getType(); + assert((SrcTy->isIntegerTy() || SrcTy->isPointerTy()) && + (Ty->isIntegerTy() || Ty->isPointerTy()) &&...

...p message is also in the attachments. > > > > Investigations > > 1. SCEV-AA try to ‘minus' the SCEV expressions of the given two > pointers(lib/Analysis/ScalarEvolutionAliasAnalysis.cpp:64) > > 2. ScalarEvolution::getMinusSCEV will boil down into > ScalarEvolution::getAddExpr. On line 2383 of > lib/Analysis/ScalarEvolution.cpp, GroupByComplexity is invoked. > > 3. CompareSCEVComplexity is eventually called to give a partial order > between two SCEV expression. > > 4. If there are two SCEVAddExpr that are located in different loops > which don’t have...

Dear All, Is the following patch to ScalarEvolution correct? It seems that without it, the enclosing for loop could skip over SCEVAddRecExpr's in the Ops[] array. -- John T. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scpatch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080222/3ff8edd7/attachment.ksh>

> I'm not following your example.  If you have two sibling loops with the same parent, one will frequently, but not always dominate the other.  Can you give a specific example of when forming a recurrence between two siblings (without one dominating the other), is useful? The situation can happen with guarded loops or with a user guard like below: if (c) { for (i = 0; i < n; i++)

Note that there is a slight difficulty due to the fact that we "sink" the trunc: (zext i16 {0,+,1}<%bb> to i32) + (65536 * ({0,+,1}<nuw><%bb> /u 65536) Here the recurrence lost it's <nuw> and got reduced to a i16 (on the left), but not on the right. But we can prove: - that (zext i16 {0,+,1}<%bb> to i32) has the same 16 LSB than (i32

+CC llvm-dev On Tue, May 8, 2018 at 2:34 AM, Gal Zohar <Gal.Zohar at ceva-dsp.com> wrote: > I noticed that SCEV, when trying to perform strength reduction, doesn’t use > the ability to prove an induction variable does not signed/unsigned wrap due > to infinite loops. > > Is there an easy way to use the isAddRecNeverPoison function when > determining if strength reduction

On Wed, Aug 24, 2016 at 3:07 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Fri, Aug 19, 2016 at 3:57 PM, Wei Mi via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> SCEV expansion sometimes generates redundent expr even if there is an >> available expr which can be reused. The redundent exprs can be a lot >> different from existing

...ompute loop iteration >> number, >> so it doesn't involve SCEV expansion. > > So how are you thinking about moving forward here? Shorterm I feel easy to try is to enhance the expansion of SCEVNAryExpr: As suggested by Andy, for a new SCEV C = A1 + A2 + B which is generated by getAddExpr(A, B), adding an opaque value node somewhere to record C equals to opaque_value = Value_A + Value_B. It is possible that B doesn't have Value_B recorded in ExprValueMap. Need to find some representation saying opaque_value = Value_A + expand(B). This will relieve the problem in PR29065. I may e...

Hi all, This is about a project I've been prototyping on-and-off for a while that has finally reached a point where I can claim it to be "potentially viable". I'd like to gather some input from the community before moving too far ahead. # The problem There is a representation issue within SCEV that prevents it from fully using information from nsw/nuw flags present in the