similar to: [LLVMdev] SCEV implementation and limitations, do we need "pow"?

On 2/7/14, 10:24 AM, Andrew Trick wrote: > > On Feb 5, 2014, at 12:54 AM, Mehdi Amini <mehdi.amini at silkan.com > <mailto:mehdi.amini at silkan.com>> wrote: > >> Hi, >> >> I was looking at some bugs to play with, and I started with >> http://llvm.org/bugs/show_bug.cgi?id=18606 >> >> As I commented there, a loop is unrolled and exhibit

Hi, I'm working on a slow-compile problem caused by SCEV (PR28830), and I need your suggestions on how to fix it. The loop below causes ScalarEvolution::getMulExpr to hang. int get(unsigned n) { unsigned i, j, mult = 1; for (i = 0; i < 1; i++) { for (j = 0; j < 30; j++) { mult *= n++; } } return mult; } the inner loop is completed unrolled

Hi folks, I'm trying to analyse this piece of IR: for.body: ; preds = %for.body, %entry %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ] %0 = shl nsw i64 %indvars.iv, 1 %arrayidx = getelementptr inbounds i32* %b, i64 %0 %1 = load i32* %arrayidx, align 4, !tbaa !1 %add = add nsw i32 %1, %I %arrayidx3 = getelementptr

On Nov 13, 2013, at 3:39 AM, Renato Golin <renato.golin at linaro.org> wrote: > Hi folks, > > I'm trying to analyse this piece of IR: > > for.body: ; preds = %for.body, %entry > %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ] > %0 = shl nsw i64 %indvars.iv, 1 > %arrayidx = getelementptr inbounds

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

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

Hi Preston, I was wondering ... "Bottom" is a bit overloaded as far as terms go. Would SCEVNaN be a better name for this beast? Sameer. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Sameer Sahasrabuddhe > Sent: Monday, October 08, 2012 9:16 AM > To: preston.briggs at gmail.com > Cc: LLVM

On 16 November 2013 06:56, Andrew Trick <atrick at apple.com> wrote: > - getMulExpr constructs a new AddRec with NSW: > > Flags = AddRec->getNoWrapFlags(clearFlags(Flags, SCEV::FlagNW)); > const SCEV *NewRec = getAddRecExpr(NewOps, AddRecLoop, Flags); > Hi Andrew, Thanks for looking at this. Clearing the flags here makes sense, but it's being too

Hi, I noticed an inconsistency in how ScalarEvolution orders instruction operands. This inconsistency can result in creation of separate (%a * %b) and (%b * %a) SCEVs as demonstrated by the example IR below (attached as gep-phi.ll)- target datalayout = "e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128" define void @foo(i8* nocapture %arr, i32 %n, i32* %A, i32* %B) local_unnamed_addr {

Hi, I am looking at two very simple kernels. They implement the following loops: constant_bound(): for (int i = 0; i < 100; i+=4); parameteric_bound(): for (int i = 0; i < n; i+=4); For the first loop SCEV is able to derive the number of loop iterations, for the second loop it returns 'Unpredictable backedge-taken count'. Is this expected because it is a difficult problem or

> On Nov 16, 2013, at 4:11 AM, Renato Golin <renato.golin at linaro.org> wrote: > >> On 16 November 2013 06:56, Andrew Trick <atrick at apple.com> wrote: >> - getMulExpr constructs a new AddRec with NSW: >> >> Flags = AddRec->getNoWrapFlags(clearFlags(Flags, SCEV::FlagNW)); >> const SCEV *NewRec = getAddRecExpr(NewOps, AddRecLoop,

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

Hi, i am playing the ScalarEvolution these days. i found the the ScalarEvolution will simply return a SCEVUnknow for a ICmpInst, so i think maybe great to add a new kind of SCEV to the ScalarEvolution framework. for example, if i run ScalarEvolution on the bc file generate from the following C source file: int f(int a, int b, int c, int d) { return (2 * a + 5 * c + 2) > (4 * d - 3*b

Thanks for fixing this Sanjoy! I do have a few questions/suggestions on the fix if you don't mind. 1) Would this work correctly if the values are call instructions with no operands, like this- %a = foo() %b = bar() 2) From the way this function is set up, it looks like the emphasis is on saving compile time by trading off robustness. Is compile time such a big concern here that we want to

test.c : ----------------------------------------------------------------------- int foo(int a) { int zero = 0; for (int i = 0; i < 10000; i++) zero *= a; return zero; } ------------------------------------------------------------------------- run clang : clang -O2 -S test.c -o test.s My clang version is 3.7.1. We will get a horrible assembly output. Why constant propagation and

Hi, Yes SCEV is pretty limited on this aspect. This kind of code can trigger LLVM to explode in time/memory: https://llvm.org/bugs/show_bug.cgi?id=18606 <https://llvm.org/bugs/show_bug.cgi?id=18606> See also this llvm-dev thread: SCEV implementation and limitations, do we need "pow"? : http://lists.llvm.org/pipermail/llvm-dev/2014-February/070062.html CC: Sanjoy who may have an

On Mon, Oct 12, 2009 at 8:22 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Mon, Oct 12, 2009 at 6:15 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: >> I have a test case(attached as fc_long.ll) that when run through the >> optimizer produces 65bit integer math(fc_long-opt.ll). >> >> >> >> Now I understand that llvm can have any

Ty Eli for your answer. On Tue, Jan 17, 2017 at 8:11 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/17/2017 7:12 AM, Thomas RUBIANO via llvm-dev wrote: > >> Hi all! >> >> I'm new here, and would like to implement my own Loop Invariant Detection >> adding some more information on Quasi-Invariants. >> >> First, is there anything

On Mar 12, 2014, at 4:05 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Wed, Mar 12, 2014 at 3:50 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > In order to vectorize code like this LLVM needs to prove that “A[i*7]” does not wrap in the address space. It fails to do so > > But, why? > > I'm moderately sure that neither C nor C++

On Wed, Jan 18, 2017 at 8:05 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/18/2017 2:56 AM, Thomas RUBIANO wrote: > > Ty Eli for your answer. > > On Tue, Jan 17, 2017 at 8:11 PM, Friedman, Eli <efriedma at codeaurora.org> > wrote: > >> On 1/17/2017 7:12 AM, Thomas RUBIANO via llvm-dev wrote: >> >>> Hi all! >>>