similar to: Floating Point SCEV Analysis

For reference, the case with a variable loop count is filed as PR27894: https://llvm.org/bugs/show_bug.cgi?id=27894 And the case with a constant loop count is filed as PR27899: https://llvm.org/bugs/show_bug.cgi?id=27899 On Thu, Jun 2, 2016 at 7:48 AM, Demikhovsky, Elena via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I implemented IV simplification with FP SCEV and uploaded a new

Hi, I'm working now on extending SCEV Analysis and adding FP support. At the beginning, I want to vectorize this loop: float fp_inc; float x = init; for (int i=0;i<N;i++){ A[i] = x; x += fp_inc; // Loop invariant variable or constant } In this loop "x" is a FP induction variable. But it is not the "primary" induction and loop trip count is still depends

> On May 16, 2016, at 5:35 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Sanjoy Das via llvm-dev" <llvm-dev at lists.llvm.org> >> To: escha at apple.com >> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Michael V Zolotukhin" <michael.v.zolotukhin at

[+CC Andy] Hi Elena, I don't have any fundamental issues with teaching SCEV about floating point types, but given this will be a major change, I think a high level roadmap should be discussed on llvm-dev before we start reviewing and committing changes. Here are some issues that I think are worth discussing: - Core motivation: why do we even care about optimizing floating point

Hi Hideki, I like this summary overall, thanks. More below. > On May 20, 2016, at 10:04 AM, Saito, Hideki <hideki.saito at intel.com> wrote: > > > To the best of my experience, handling case B (secondary induction) is must-have, and if I’m not mistaken, > people aren’t opposed to that. > > For me, handling case A (primary induction) is “why not?”, but I certainly

To the best of my experience, handling case B (secondary induction) is must-have, and if I’m not mistaken, people aren’t opposed to that. For me, handling case A (primary induction) is “why not?”, but I certainly admit that that can be very naïve thinking coming from lack of good understanding on SCEV and their proper usages. Now, let’s assume we can postpone discussion about case A. What is the

Adding support for FP inductions through isInductionPHI() is certainly possible, I have a relatively small local patch that does exactly that for simple fp add-recurrence cases, along with changes to the vectorizer to make it aware of FP inductions. It won't get give you the powerful reasoning capabilities of SCEV, but for the B-like cases it should work. Amara On 20 May 2016 at 19:31, Adam

Hi, On Sun, Aug 13, 2017 at 5:58 AM, Anastasiya Ruzhanskaya via llvm-dev <llvm-dev at lists.llvm.org> wrote: > And still, aren't there any possibilities to find that phi node, that led > SCEV to compute max trip count? So there is no good answer to your question since in most cases SCEV does not directly look at PHI nodes (or expressions based off of the PHI node). It converts

> One option would be to extend InductionDescriptor::isInductionPHI in the vectorizer to directly analyze the PHIs without SCEV support as Sanjoy suggested. I *think* that that could be sufficient to handle case B. I implemented this with FP SCEV and the code looks very structured, including SCEVExpander. Extending the existing structures without implementing FP SCEV will be problematic. And

To continue this topic: sometimes SCEV's behavior is rather controversial : for loops with i changing as i \=2 for example, he can't figure what the type of expressions is, but surprisingly can determine max trip count. Shouldn't it be able to detect or not detect these parameters at the same time? 2017-08-11 15:56 GMT+02:00 Anastasiya Ruzhanskaya < anastasiya.ruzhanskaya at

On Sat, Aug 27, 2016 at 7:07 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Wei Mi via llvm-dev" <llvm-dev at lists.llvm.org> >> To: "Daniel Berlin" <dberlin at dberlin.org> >> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "David Li" <davidxl at google.com> >> Sent:

Demikhovsky, Elena wrote: > > Even then, I'd personally want to see further evidence of why the > correct solution is to model the floating point IV in SCEV rather than > find a more powerful way of converting the IV to an integer that models > > the non-integer values taken on by the IV. As an example, if the use > case is the following code with appropriate flags to

Thanks for the feedback, Sanjoy. > SCEV is fairly conservative around PHI nodes that aren't recurrences and aren't obviously equivalent to a min-max branch-phi idiom. Is that the limitation you're running into here? Yes, that's exactly the problem. The problematic PHI nodes (%bc.resume.val and %bc.resume.val1) aren't either recurrences or related to min-max idioms. I

On Tue, May 17, 2016 at 8:49 PM Owen Anderson <resistor at mac.com> wrote: > > On May 16, 2016, at 2:42 PM, Sanjoy Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > - Core motivation: why do we even care about optimizing floating > point induction variables? What situations are they common in? Do > programmers _expect_ compilers to optimize them

Hi Geoff, On Wed, Aug 9, 2017 at 8:58 AM, Geoff Berry <gberry at codeaurora.org> wrote: > On 8/8/2017 8:38 PM, Sanjoy Das wrote: >> >> Hi, >> >> On Tue, Aug 8, 2017 at 12:58 PM, Friedman, Eli <efriedma at codeaurora.org> >> wrote: >>> >>> Oh, I see... yes, we do stupid things involving mutating NoWrap flags >>> after

Hi, On Tue, Aug 8, 2017 at 12:58 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > Oh, I see... yes, we do stupid things involving mutating NoWrap flags after > a SCEV is created. (grep for setNoWrapFlags in ScalarEvolution.cpp.) That's really a compile time hack -- we defer some expensive tricks to prove nsw/nuw on an add recurrences to when we've been asked to

> On Aug 14, 2017, at 7:35 AM, Geoff Berry <gberry at codeaurora.org> wrote: > > Hi Sanjoy, > > [adding Adam since I believe he added the original FIXME to preserve SCEV > in LoopDataPrefetch] For record, that wasn’t me. It was there from the beginning when Hal added the PPC-specific pass. Adam > > On 8/14/2017 1:36 AM, Sanjoy Das wrote: >> Hi Geoff,

Hi! I would appreciate some feedback from someone with experience in SCEV/SE. D39346 tries to fix an issue in LV (PR34965) that exposes a limitation in SCEV/SE. The best solution to the LV issue might not be a fix at SCEV/SE level but we may want to report/address SCEV/SE limitation as well. For the snippet below, LV expects SE to return a SCEVAddRecExpr for %21. However, SE returns ((4 * (zext

Thanks Sanjoy, I'll look into this. -----Original Message----- From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] Sent: Thursday, May 10, 2018 8:07 AM To: Nema, Ashutosh <Ashutosh.Nema at amd.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] ScalarEvolution questions Hi Ashutosh, On Wed, May 9, 2018 at 3:28 AM, Nema, Ashutosh via llvm-dev <llvm-dev at

Thanks for your insides Sanjoy! I don't really believe that option 2 may work just because even if we recalculate the range for this add recurrency, there are already its derivatives with cached ranges (the most obvious example is sext and expressions where this sext is involved). We can speculate about what is "simple enough" to not cache the ranges, but I believe that there is