similar to: LSR/SCEV problem/question

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

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 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)

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 Andrew, The issue below refers to LSR, so I'll appreciate your feedback. It also refers to instruction combining and might impact backends other than X86, so if you know of others that might be interested you are more than welcome to add them. Thanks, Anat _____________________________________________ From: Shemer, Anat Sent: Tuesday, February 18, 2014 15:07 To: 'llvmdev at

The Loop Strength Reduction pass appears to break debug information even for the most basic input. I believe this is a well known issue already (see https://bugs.llvm.org/show_bug.cgi?id=38815) but I also believe that it deserve some extra attention. Consider the following input compiled with 'clang -g -O3 foo.c -mllvm -print-after-all' --- void foo(unsigned char *p) { #pragma clang loop

*** Summary I'd like to propose (and implement) functionality in LLVM to determine when a poison value from an instruction is guaranteed to produce undefined behavior. I want to use that to improve handling of nsw, inbounds etc. flags in scalar evolution and LSR. I imagine that there would be other uses for it. I'd like feedback on this idea before I proceed with it. *** Details Poison

I just filed bug 7872 about non-scalability of the LSR analysis algorithms. It may be related to bug 6727. The fundamental problem appears to be re-running SCEV analyses such as properlyDominates and SCEVComplexityCompare over and over again on large SCEV expressions. Memoizing results for SCEVComplexityCompare appears to help significantly but that is much harder to do with things like

This is related to an issue in loop strength reduction [1] that I've been trying to fix on and off for a while. [1] has a more detailed description of the issue and an example, but briefly put, I want LSR to consider formulae that have "Zext T" as base and/or scale registers, and to appropriately rate such formulae. My first attempt[2] at fixing this was buggy and had to be

> Of course, and the point is that, for example, on x86_64, the zext here is free. I'm still trying to understand the problem... > > In the example you provided in your previous e-mail, we choose the solution: > > `GEP @Global, zext(V)` -> `GEP (@Global + zext VStart), {i64 0,+,1}` > `V` -> `trunc({i64 0,+,1}) + VStart` > > instead of the actually-better

On Jun 24, 2013, at 11:01 AM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > Hi, > > I wanted to start a discussion about the following issue since I am not sure about what to do about it: > > The loop-vectorizer has the potential to make code a quite a bit bigger (esp. in cases where we don’t know the loop count or whether pointers alias). > Chandler has

Hi Andy, Actually, if we just add hooks that preserves the existing behavior, It is not difficult. For example, For case one, we can define one function like virtual const SCEV* getTargetPreferredWinnerReg(const SCEV*& ScaledReg, SmallVector<const SCEV *, 4>& BaseRegs, GlobalValue*& BaseGV) const; In NarrowSearchSpaceByPickingWinnerRegs, we can

On Mar 13, 2013, at 4:37 PM, Yin Ma <yinma at codeaurora.org> wrote: > Hi All, > > In the target I am working, we comes cross a situation that the loop strength reduction > could deliver a better result but currently not, because > 1. the algorithm narrows search space by winner registers without considering > the target preferred format.

----- Original Message ----- > From: "Yin Ma" <yinma at codeaurora.org> > To: "Andrew Trick" <atrick at apple.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Thursday, March 14, 2013 4:21:50 PM > Subject: Re: [LLVMdev] Suggestion About Adding Target Dependent Decision in LSR Please > > > > > > Hi Andy, > > > > Actually,

Hi All, In the target I am working, we comes cross a situation that the loop strength reduction could deliver a better result but currently not, because 1. the algorithm narrows search space by winner registers without considering the target preferred format. (NarrowSearchSpaceByPickingWinnerRegs) 2. Cost comparison solely favors the number register without considering other

Hi, I wanted to start a discussion about the following issue since I am not sure about what to do about it: The loop-vectorizer has the potential to make code a quite a bit bigger (esp. in cases where we don’t know the loop count or whether pointers alias). Chandler has observed this in snappy where we have a simple memory copying loop (that may overlap). We vectorize this loop and then this

> 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

> I don't understand why you want to factor out the information, > exactly. It seems like what you need is a function like: > > unsigned getMinLeadingZeros(const SCEV *); > > then, if you want to get the non-extended expression, you can just > apply an appropriate truncation. I assume, however, that I'm missing > something. The problem is not about how to codegen

> To back up for a second, how much of this is self-inflicted damage? > IndVarSimplify likes to preemptively widen induction variables. Is > that why you have the extensions here in the first place? In the specific example I was talking about the zext came from our frontend (our FE used to insert these extensions for reasons that are no longer relevant). But you can easily get the same

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