search for: expandcodefor

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 state, no hidden state transitions, so it's locally clear to a reader how the IRBuilder moves. Cheers, Philip 2018-04-29 20:50 GMT+02:00 Sanjo...

...p Pfaffe via llvm-dev, < llvm-dev at lists.llvm.org> wrote: > 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 state, no hidden state transitions, so it's locally clear to a > reader how the IRBuilder moves. > > Cheers, > Ph...

...EVExpander, 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 expandCodeFor the closed form. This allows the folders to // simplify the expression without having to build a bunch of special code // into this folder. SCEVHandle IH = SE.getUnknown(I); // Get I as a "symbolic" SCEV. SCEVHandle V = S->evaluateAtIteration(IH, SE); //cerr << &quo...

.... 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. Add a boolean...

...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 expandCodeFor the closed form. This allows the folders to > // simplify the expression without having to build a bunch of special code > // into this folder. > SCEVHandle IH = SE.getUnknown(I); // Get I as a "symbolic" SCEV. > > SCEVHandle V = S->evaluateAtIteration(IH, SE...

Hi Geoff, Firstly, I think it will be great if you have a small reproducer of this issue (which I can make fail after re-applying D18001 to ToT). > I’ve run into what appears to be a bug in ScalarEvolution, but I’m not sure > if it is instead caused by me missing an implicit assumption between LSR and > SCEV. > > This issue is caused by the change D18001, which is an attempt to

...;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 expandCodeFor the closed form. This allows the > > folders to // simplify the expression without having to build a bunch of > > special code // into this folder. > > SCEVHandle IH = SE.getUnknown(I); // Get I as a "symbolic" SCEV. > > > > SCEVHandle V = S->evalua...

...eally* 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...

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 llvm-dev

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, SCEVExpander inherit from IRBuilder and basically extend it with SCEV

Hi All, I've run into what appears to be a bug in ScalarEvolution, but I'm not sure if it is instead caused by me missing an implicit assumption between LSR and SCEV. This issue is caused by the change D18001 <http://reviews.llvm.org/D18001> , which is an attempt to increase SCEV-inserted instruction re-use by picking a more canonical insertion position in the case where a new

...ent 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...