search for: isknownpredicate

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 perhaps use it for a "bottom" value. Think it would work? Thanks, Prest...

Hello all, I was looking for an analysis pass that could provide comprehensive information on pointer arithmetic in the context of whole-program optimization. It seems that Scalar Evolution provides exactly what I'm looking for, but it is restricted to only intraprocedural analysis. E.g., consider this toy snippet: void foo(int* p) { (*p)++; } int bar() { int i; for (i = 0; i < n;

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::Unknown. The documentation suggests I could perhaps use it for > a "bottom" value. &...

Hi Nick, I checked in something towards (1) yesterday -- http://reviews.llvm.org/D6748 I was under the impression that (2) is exactly the kind of predicate ScalarEvolution::isKnownPredicate is designed to solve (using isImpliedCondXXX or something like that). Is there a reason to prefer GVN over that? On Wed, Jan 7, 2015 at 10:06 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Sanjoy Das wrote: >> >> Hi all, >> >> I'm trying to get llvm to optimiz...

I'd missed the fact that j wasn't just being decremented. This isn't as easy as I said. Philip On 03/03/2016 02:36 PM, Philip Reames via llvm-dev wrote: > SCEV should be able to easily prove that j is positive here. I'm not > sure where the right place to use that information would be in this > case. Sanjoy, can you comment? > > Philip > > On 03/03/2016

...ue > > 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::Unknown. The documentation suggests I could perhaps use it for > &...

...ke `(-3 + (sext i32 %m to i64) + (-1 * (zext i32 %m to > i64))<nsw>)`. While we cannot reduce expressions of this form in general, it > does pose a sever limitation for the vast majority of cases where the loop > upper bound is non-negative. > There are already some function like isKnownPredicate that attempt to deal with some of this is DA. Can we extend the other for these cases? Perhaps with some extra information that we have that SCEV would in general not know, or do something extra that it would not compute. Or ideally can we just improve SCEV to get this right? > Regarding your e...

...surrounding code (because the predicates aren't known to be true at that point, we need to search different predecessors to find one in which the conditions might be true and insert the vector loop across that predecessor edge instead). Maybe we could do this, for example, by calling SE->isKnownPredicate enhanced with some additional context sensitivity because we currently check dominating conditional branches for things that are AddRecs in some loop? Moreover, we then have the problem of restructuring the order of the trip-count checks (because we need to fast fail to the scalar loop for the...

...larEvolution, ValueTracking, etc. the benefit of analyzing these invariants in normalized form. The next step is introducing some way to use these invariants. I think that a natural place is to integrate these is with ScalarEvolution. We'd want functions like getUnsignedRange, isKnownNegative, isKnownPredicate, etc. to automatically take advantage of declared invariants. Internally, SE uses a function: /// isImpliedCondOperands - Test whether the condition described by Pred, /// LHS, and RHS is true whenever the condition described by Pred, FoundLHS, /// and FoundRHS is true. bool isImpli...

...nt. Dave From: Bardia Mahjour Sent: 22 May 2019 18:09 To: David Green Cc: Doerfert, Johannes; llvm-dev at lists.llvm.org; nd Subject: Re: Re: [llvm-dev] Delinearization validity checks in DependenceAnalysis   Hi David, Sorry for my delayed response. > There are already some function like isKnownPredicate that attempt to deal with some of this is DA. Can we extend the other for these cases? Perhaps with some extra information that we have that SCEV would in general not know, or do something extra that it would not compute. Or ideally can we just improve SCEV to get this right? It looks like SCEV al...

...ates aren't known to be true >> at that point, we need to search different predecessors to find one >> in which the conditions might be true and insert the vector loop >> across that predecessor edge instead). Maybe we could do this, for >> example, by calling SE->isKnownPredicate enhanced with some >> additional context sensitivity because we currently check dominating >> conditional branches for things that are AddRecs in some loop? >> Moreover, we then have the problem of restructuring the order of the >> trip-count checks (because we need to f...

Hi all, I'm trying to get llvm to optimize away the %cmp to true in define i32 @foo(i32* %array, i32* %length_ptr, i32 %init) { entry: %length = load i32* %length_ptr, !range !0 %len.sub.1 = sub i32 %length, 1 %upper = icmp slt i32 %init, %len.sub.1 br i1 %upper, label %loop, label %exit loop: %civ = phi i32 [ %init, %entry ], [ %civ.inc, %latch ] %civ.inc = add i32 %civ, 1

On 03/14/2017 11:21 AM, Adam Nemet wrote: > >> On Mar 14, 2017, at 6:00 AM, Nema, Ashutosh <Ashutosh.Nema at amd.com >> <mailto:Ashutosh.Nema at amd.com>> wrote: >> >> Summarizing the discussion on the implementation approaches. >> Discussed about two approaches, first running ‘InnerLoopVectorizer’ >> again on the epilog loop immediately after

...7f8d690b3972 (/lib64/libc.so.6+0x2f972) #9 0x0000000002f60e6b llvm::ScalarEvolution::isLoopEntryGuardedByCond(llvm::Loop const*, llvm::CmpInst::Predicate, llvm::SCEV const*, llvm::SCEV const*) /home/dwmw2/git/llvm/lib/Analysis/ScalarEvolution.cpp:9110:0 #10 0x0000000002f5f6d1 llvm::ScalarEvolution::isKnownPredicate(llvm::CmpInst::Predicate, llvm::SCEV const*, llvm::SCEV const*) /home/dwmw2/git/llvm/lib/Analysis/ScalarEvolution.cpp:8672:0 #11 0x0000000003a40edf (anonymous namespace)::WidenIV::pushNarrowIVUsers(llvm::Instruction*, llvm::Instruction*) /home/dwmw2/git/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp...

Hi David, Thank you very much for your response. I also get correct results for my example (for a 64-bit target) if the upper bounds are changed to unsigned. The reason is simply because clang zero-extends `m` for address calculations but sign-extends it for the loop upper bound. This prevents SCEV from canceling out the 'm' term from the difference expression that looks like `(-3 +

I've landed the patch in r324449. Before we merge this into two different Clang release branches and almost immediately release one of them, I would really like someone to confirm that this patch works well with the Linux kernel. David, if you're up for that, it would be great. Alternatively, Guenter or someone else here can help. On Tue, Feb 6, 2018 at 5:59 PM Chandler Carruth

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