similar to: SCEVExpander and IRBuilder

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

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

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 Philip Pfaffe via llvm-dev, < llvm-dev at

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

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

Hi everybody, I'm investigating some correctness issues with debug line table information in optimized code. I've noticed something problematic in IRBuilder. Setting the insertion point of an IRBuilder sets the builder’s current debug loc to the one attached to the insertion point. IMO this isn't always a correct or convenient thing to do, and it shouldn't be the default behavior.

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

> On Nov 6, 2017, at 2:32 PM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Nov 6, 2017, at 2:19 PM, Vedant Kumar <vsk at apple.com> wrote: >> >> Hi everybody, >> >> I'm investigating some correctness issues with debug line table information in optimized code. I've noticed something problematic in IRBuilder. Setting the

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)

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

> On Aug 23, 2016, at 11:30 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Wei, > > 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

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

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

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

Hi Wei, Wei Mi wrote: > Sanjoy and Andy, thanks a lot for your suggestions. > > On Wed, Aug 24, 2016 at 8:53 AM, Andrew Trick<atrick at apple.com> wrote: >> >>> On Aug 23, 2016, at 11:30 PM, Sanjoy Das<sanjoy at playingwithpointers.com> wrote: >>> >>> Hi Wei, >>> >>> I've not seen GCC's SCEV so I cannot

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 >

Hi, The IRBuilder is currently templated over a constant folder, and an instruction inserter. https://reviews.llvm.org/D73835 proposes to move this towards using virtual dispatch instead. As this is a larger design change, I would like to get some feedback on this. The current templated design of IRBuilder has a couple of problems: 1. It's not possible to share code between use-sites that

I've got a ticket open where I would very much like some input from maintainers of other languages that rely on llvm and use the IRBuilder. See: Teach the IRBuilder about constrained fadd and friends: https://reviews.llvm.org/D53157 I'm adding support to functions like CreateFAdd() the ability to optionally emit the constrained math intrinsics required to support strict floating point

On Friday 27 February 2009 00:50, Nick Lewycky wrote: > 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,

Hi LLVM, IRBuilder can fold constants (that behaviour can be controlled by Folder type). What do you think about optionally allow IRBuilder to eliminate no-op instructions like `add %a, 0` or `memcpy(%a, %b, 0)`? - Paweł -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150423/4f99a092/attachment.html>