similar to: LSR/SCEV problem/question

Displaying 20 results from an estimated 5000 matches similar to: "LSR/SCEV problem/question"

2016 Mar 24
0
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
2016 Mar 23
0
LSR/SCEV problem/question
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
2016 Mar 30
0
LSR/SCEV problem/question
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)
2012 May 30
2
[LLVMdev] [llvm-commits] [llvm] r157649 - /llvm/trunk/lib/Transforms/Scalar/BoundsChecking.cpp
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
2014 Feb 19
2
[LLVMdev] better code for IV
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
2020 Sep 10
2
LSR breaks debug info
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
2015 Jun 26
6
[LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution
*** 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
2010 Aug 11
2
[LLVMdev] LSR is Unbearably Slow
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
2015 Aug 17
2
RFC for a design change in LoopStrengthReduce / ScalarEvolution
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
2015 Aug 18
2
RFC for a design change in LoopStrengthReduce / ScalarEvolution
> 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
2013 Jun 24
0
[LLVMdev] [llvm] r184698 - Add a flag to defer vectorization into a phase after the inliner and its
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
2013 Mar 14
3
[LLVMdev] Suggestion About Adding Target Dependent Decision in LSR Please
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
2013 Mar 14
0
[LLVMdev] Suggestion About Adding Target Dependent Decision in LSR Please
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.
2013 Mar 14
0
[LLVMdev] Suggestion About Adding Target Dependent Decision in LSR Please
----- 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,
2013 Mar 13
2
[LLVMdev] Suggestion About Adding Target Dependent Decision in LSR Please
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
2013 Jun 24
8
[LLVMdev] [llvm] r184698 - Add a flag to defer vectorization into a phase after the inliner and its
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
2016 Aug 24
3
Request suggestions about how to remove redundencies caused by SCEV expansion fundementally
> 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
2015 Aug 17
4
RFC for a design change in LoopStrengthReduce / ScalarEvolution
> 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
2015 Aug 17
2
RFC for a design change in LoopStrengthReduce / ScalarEvolution
> 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
2016 Aug 24
3
Request suggestions about how to remove redundencies caused by SCEV expansion fundementally
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