search for: scevexpander

Hello, I use SCEVExpander and IRBuilder to generate some code and I frequently end-up breaking dominance because the SCEVExpander insertion point and the IRBuilder insertion point do not advance in synchrony. Ideally, I could build a SCEVExpander based on an existing IRBuilder (so that they move each other). Or even better...

Hi Alex, Sanjoy, exposing the internal IRBuilder to users of SCEVExpander violates information hiding, and encourages the tight coupling that makes code bases such as Polly so hard to maintain. SCEVExpander::expandCodeFor returns a Value that (if it's an instruction) can be used to update the insert point of the client's IRBuilder. Is that not enough? No hidden...

Hi Alexandre, Sorry I missed this -- I was on vacation when you sent this. SCEVExpander already has an IRBuilder in it but AFAICT it isn't exposed as a public interface. I'd be fine if you wanted to expose a public `GetIRBuilder()` accessor that let a SCEVExpander client use the same IRBuilder as SCEVExpander. -- Sanjoy On Fri, Apr 6, 2018 at 10:55 AM, Alexandre Isoard via...

Hey, Alternatively, expose a SCEVExpander::getInsertPoint? This would proxy the underlying IRbuilder, with no real state sharing, other than the current insert point. This will be less ugly than recieving the expanded SCEV value, casting to an instruction, and feeding this to the IRBuilder. Cheers, siddharth On Thu 3 May, 2018, 15:36 Ph...

Originally on llvm-commits. On May 30, 2012, at 8:48 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: >> This is probably fine for now. It's a relatively safe use of SCEVExpander and the least effort approach, but generally I would like to encourage people to solve local rewrite problems with IRBuilder, not SCEVExpander, and build useful utilities for that purpose. Just because you use SCEV doesn't mean you have to use SCEVExpander. SCEVExpander may try to do more rewri...

...gt; I've not seen GCC's SCEV so I cannot make a comparative comment here > (maybe Chris, Andy or Dan can chime in here), but I personally am in > the "make the cleanup passes smarter" camp. We can also try to make > SCEV expansion smarter -- not by putting more things in SCEVExpander > (it is already complex enough!), but by splitting out a dedicated > SCEVSimplifier that you invoke on code generated from SCEVExpander to > strength reduce it. SCEVSimplifier can then internally use routines > in SCEV, so that it is "as smart as" SCEV in most cases. > &...

...e SCEV-inserted instruction re-use by picking a more canonical insertion position in the case where a new insert position block is not found. The problem I have run into with this change is that it causes an insert position instruction to be chosen which is later hoisted into a different block by SCEVExpander::hoistIVInc(). This in turn makes the SCEVExpander Builder InsertPt inconsistent (the instruction and block end up not matching), which leads to an invalid instruction being inserted (with its parent != its containing block). Does anyone more familiar with the design of the LSR/SCEV interactio...

...ion re-use by picking a more canonical insertion > position in the case where a new insert position block is not found. > > The problem I have run into with this change is that it causes an insert > position instruction to be chosen which is later hoisted into a different > block by SCEVExpander::hoistIVInc(). This in turn makes the SCEVExpander When is the insert position moved? IOW, what is the "timeline" of events? There are two calls to hoistIVInc in SCEVExpander, in getAddRecExprPHILiterally and in replaceCongruentIVs -- which one is the problematic case? > Builder I...

Hi, We have recently encountered incorrect code generation issues and I think it is a SCEVExpander bug exposed by a recent patch to add nuw/nsw flags when generating code for SCEVMulExpr. The test case IR looks like this- %1 = load i16, i16* %arrayidx %2 = and i16 %1, -32768 The SCEV form of %2 is this- (-32768 * (%1 /u -32768))<nuw><nsw> It has both nsw/nuw flags. The signed ran...

On Wed, 30 May 2012 10:04:50 -0700 Andrew Trick <atrick at apple.com> wrote: > Originally on llvm-commits. > > On May 30, 2012, at 8:48 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > >> This is probably fine for now. It's a relatively safe use of > >> SCEVExpander and the least effort approach, but generally I would > >> like to encourage people to solve local rewrite problems with > >> IRBuilder, not SCEVExpander, and build useful utilities for that > >> purpose. Just because you use SCEV doesn't mean you have to use > >...

We've upgraded to llvm 2.4 and we're hitting an assert in SCEV: llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h:669: RetVal llvm::SCEVVisitor<SC, RetVal>::visitCouldNotCompute(llvm::SCEVCouldNotCompute*) [with SC = llvm::SCEVExpander, RetVal = llvm::Value*]: Assertion `0 && "Invalid use of SCEVCouldNotCompute!"' failed. This happens in SCEVExpander::visitAddRecExpr where we drop down to this code: // If this is a chain of recurrences, turn it into a closed form, using the // folders, then expandCode...

...39;s SCEV so I cannot make a comparative comment here >>> (maybe Chris, Andy or Dan can chime in here), but I personally am in >>> the "make the cleanup passes smarter" camp. We can also try to make >>> SCEV expansion smarter -- not by putting more things in SCEVExpander >>> (it is already complex enough!), but by splitting out a dedicated >>> SCEVSimplifier that you invoke on code generated from SCEVExpander to >>> strength reduce it. SCEVSimplifier can then internally use routines >>> in SCEV, so that it is "as smart...

Hi Geoff, How was it handled before your change? Were we just lucky that insert points always matched? Would it be possible to move all the logic for finding a proper insertion into SCEVExpander? I think that is ultimately the best solution for this, but I have to admit I looked into this code a while ago. Michael > On Mar 23, 2016, at 9:22 AM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi All, > > I’ve run into what appears to be a bug in Sc...

David Greene wrote: > We've upgraded to llvm 2.4 and we're hitting an assert in SCEV: > > llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h:669: RetVal > llvm::SCEVVisitor<SC, > RetVal>::visitCouldNotCompute(llvm::SCEVCouldNotCompute*) [with SC = > llvm::SCEVExpander, RetVal = llvm::Value*]: Assertion `0 && "Invalid use of > SCEVCouldNotCompute!"' failed. > > This happens in SCEVExpander::visitAddRecExpr where we drop down > to this code: > > // If this is a chain of recurrences, turn it into a closed form, using the...

...; > We've upgraded to llvm 2.4 and we're hitting an assert in SCEV: > > > > llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h:669: RetVal > > llvm::SCEVVisitor<SC, > > RetVal>::visitCouldNotCompute(llvm::SCEVCouldNotCompute*) [with SC = > > llvm::SCEVExpander, RetVal = llvm::Value*]: Assertion `0 && "Invalid use > > of SCEVCouldNotCompute!"' failed. > > > > This happens in SCEVExpander::visitAddRecExpr where we drop down > > to this code: > > > > // If this is a chain of recurrences, turn it in...

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 exprs so that existing cleanup passes cannot remove them. https://llvm.org/bugs/show_bug.cgi?id=24920 https://llvm.org/bugs/show_bug.cgi?id=24442 https://reviews.llvm.org/D12090 and https://reviews.llvm.org/D21313 already relieved the

...low-insensitive universe independent of the def-use chain of values. SCEV simply can't represent the flags in most cases. I think the only flag that makes sense in SCEV is the no-wrap flag on a recurrence (that's independent of signed/unsigned overflow). As long as indvars does not rely on SCEVExpander it should be able to preserve the flags. Unfortunately, it still uses SCEVExpander in a few places. LinearFunctionTestReplace is one that should simply be moved into LSR instead. For the couple other cases, we'll just have to work on alternative implementations that don't drop flags, but I...

Hello The current svn revision fails to compile on windows using Visual Studio 2008. I'm getting: 1>ScalarEvolutionExpander.cpp 1>F:\dev\llvm\include\llvm/Analysis/ScalarEvolutionExpander.h(29) : warning C4099: 'llvm::SCEVExpander' : type name first seen using 'class' now seen using 'struct' 1> F:\dev\llvm\include\llvm/Analysis/ScalarEvolution.h(216) : see declaration of 'llvm::SCEVExpander' 1>..\..\..\lib\Analysis\ScalarEvolutionExpander.cpp(446) : error C2075: 'RestArray' :...

Hi Geoff, Thanks for the detailed reproduction instruction -- they were very helpful, and I can now see the bug. Generally, I think (2) is the better solution. It should be up to SCEVExpander to keep its state consistent. The fact that we're trying to optimize instructions as we insert them makes that trickier, but I still think that is the right invariant to have. I don't see why (2) would be particularly ugly though (perhaps I'm not being sufficiently imaginative :) )....

...'s correct. But it can be *really* inconvenient when it's incorrect. If a client sets an IRBuilder's debug loc correctly and makes a call that changes the builder's insertion point, all generated instructions will pick up a bogus debug loc from the IP. E.g this is what happens with SCEVExpander::expandCodeFor(). There's no way to fix this bug without changing IRBuilder's behavior. # Solutions 1. Add a method called SetInsertPointAndDebugLoc() which behaves identically to the current SetInsertPoint(). Change SetInsertPoint() so that it doesn't change the current debug loc. 2....