search for: scevabl

...terpretation, is that correct?). If that is the case we could be missing out for languages that have such a behavior (and in particular in C++). I was wondering how it would be viewed the possibility of adding a flag to loop deletion that allows the removal of loops with loop counts that are not SCEVable. Thanks, Marcello -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170929/4285285a/attachment.html>

...> > If that is the case we could be missing out for languages that have such a > behavior (and in particular in C++). > > I was wondering how it would be viewed the possibility of adding a flag to > loop deletion that allows the removal of loops with loop counts that are not > SCEVable. > You probably have seen it, but, for reference https://reviews.llvm.org/D38336 (which goes in the exact opposite direction). I don't necessarily fancy the idea of having a flag, instead, maybe, the frontend could emit enough information to tell the optimizer whether it is safe to remove...

Hi Ees, SCEV Delinearization is the closest I know. But it has its problems. Well for one your expression should be SCEVable. But more importantly, SCEV Delinearization is trying to deduce something that is high-level (actually source-level) from a low-level IR in which a lot of this info has been lost. So, since there's not a 1-1 mapping from high-level code to LLVM IR, going backwards will always be imperfect. A...

...the case we could be missing out for languages that have such a >> behavior (and in particular in C++). >> >> I was wondering how it would be viewed the possibility of adding a flag to >> loop deletion that allows the removal of loops with loop counts that are not >> SCEVable. >> > > You probably have seen it, but, for reference > https://reviews.llvm.org/D38336 (which goes in the exact opposite direction). > > I don't necessarily fancy the idea of having a flag, instead, maybe, > the frontend could emit enough information to tell the opt...

...be missing out for languages that have such a >>> behavior (and in particular in C++). >>> >>> I was wondering how it would be viewed the possibility of adding a flag to >>> loop deletion that allows the removal of loops with loop counts that are not >>> SCEVable. >>> >> You probably have seen it, but, for reference >> https://reviews.llvm.org/D38336 (which goes in the exact opposite direction). >> >> I don't necessarily fancy the idea of having a flag, instead, maybe, >> the frontend could emit enough information...

...t; > > > > > Am Fr., 2. Okt. 2020 um 19:25 Uhr schrieb Stefanos Baziotis via llvm-dev < > llvm-dev at lists.llvm.org>: > >> Hi Ees, >> >> SCEV Delinearization is the closest I know. But it has its problems. Well >> for one your expression should be SCEVable. >> >> But more importantly, SCEV Delinearization is trying to deduce something >> that is high-level (actually source-level) from a low-level IR in which a >> lot of this info has been lost. So, since there's not a 1-1 mapping from >> high-level code to LLVM IR,...

On Sat, Aug 27, 2016 at 7:07 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Wei Mi via llvm-dev" <llvm-dev at lists.llvm.org> >> To: "Daniel Berlin" <dberlin at dberlin.org> >> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "David Li" <davidxl at google.com> >> Sent:

...ad i32* %1524, align 4, !dbg !1371, !tbaa !693" AND "store i32 1, i32* %1532, align 4, !dbg !1381, !tbaa !693" > common nesting levels = 1 > maximum nesting levels = 1 > SrcPtrSCEV = @worm > DstPtrSCEV = @worm > using GEPs > Assertion failed: (isSCEVable(V->getType()) && "Value is not SCEVable!"), function getSCEV, file /Developer/llvm/lib/Analysis/ScalarEvolution.cpp, line 2721. > 0 libLLVM-3.3svn.dylib 0x0000000105b01cee llvm::sys::PrintStackTrace(__sFILE*) + 46 > 1 libLLVM-3.3svn.dylib 0x0000000105b01ffb PrintStackT...

Hi all, For loads and stores i want to extract information about the number of indices accessed. For instance: struct S {int X, int *Y}; __global__ void kernel(int *A, int **B, struct S) {   int x = A[..][..]; // -> L: A[..][..]   int y = *B[2];   // -> L: B[0][2]   int z = S.y[..];  // -> L: S.1[..]   // etc.. } I am performing some preprocessing on IR to: 1. Move constant