[llvm-dev] Working on FP SCEV Analysis

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Mon May 16 18:31:31 PDT 2016

```----- Original Message -----

> From: "Michael Zolotukhin" <mzolotukhin at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Sanjoy Das" <sanjoy at playingwithpointers.com>, "llvm-dev"
> <llvm-dev at lists.llvm.org>, "Michael V Zolotukhin"
> <michael.v.zolotukhin at intel.com>, "tyler nowicki"
> <tyler.nowicki at gmail.com>
> Sent: Monday, May 16, 2016 8:20:05 PM
> Subject: Re: [llvm-dev] Working on FP SCEV Analysis

> > 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 intel.com >
> >
>
> > > Sent: Monday, May 16, 2016 7:31:20 PM
> >
>
> > > Subject: Re: [llvm-dev] Working on FP SCEV Analysis
> >
>

> > > Hi Escha,
> >
>

> > > via llvm-dev wrote:
> >
>

> > > > One thought I’ve had about this in the past —
> > >
> >
>

> > > > SCEV is useful for proving two expressions are equivalent (in
> > >
> >
>
> > > > general,
> > >
> >
>
> > > > not just specifically for loop induction variables). This gets
> > > > a
> > >
> >
>
> > > > little
> > >
> >
>
> > > > bit trickier with fast-math; for example, suppose two
> > > > expressions
> > >
> >
>
> > > > are
> > >
> >
>
> > > > equivalent, but *only* with reassociativity allowed?
> > >
> >
>

> > > This isn't too different from "sext(a + b) == sext(a) + sext(b)
> > > only
> >
>
> > > if the addition is nsw".
> >
>

> > > However, it wasn't clear to me from the lang-ref what the
> > > fastmath
> >
>
> > > flags really mean. What is the semantics of a program that
> > > computes
> >
>
> > > ((a +fast b) +fast c) when ((a + b) + c) != (a + (b + c))?
> >
>

> > This is often true, and it is neither UB nor poison. The user has
> > given the compiler the freedom to choose whatever the compiler
> > decides will be most-efficient to compute. "fast math" is an odd
> > concept in that sense. It is giving the compiler the freedom to
> > change the program semantics to some extent.
>

> It’s possible to make an infinite loop finite with fast math if the
> primary IV is float. Is it acceptable behavior too? What I mean is
> that if we have
> for (float i = 0.0; i < HUGE_FLOAT_NUMBER; i += 0.5) {
> ...
> }
> we might never reach HUGE_FLOAT_NUMBER, as at some point i+1.0 = i in
> float (or am I totally wrong here?). However, when analyzing this
> loop, we might find its trip count to be exactly
> HUGE_FLOAT_NUMBER*2. There are all kinds of odd stuff with floats in
> this area, but probably if ‘-ffast-math’ is provided, we’re fine.
Great question. So, if I paraphrase the intent of "fast math" to be, "I'm only thinking about these floating-point numbers as real numbers, you can do the same", then I think the answer to your question is yes. Furthermore, that would certainly speed things up. ;)

> I’m also very interested in specific cases we want to catch here. In
> the past Tyler (CCed) looked into this problem, but as far as I
> remember we decided that complexity/gains ratio was too low.
> Basically, I anticipate that the code to support this in SCEV will
> be at least as sophisticated as for integers, but in contrast to
> integers FP induction variables are much rarer in real world
> programs, at least to my impression.
To be honest, I don't think that loops with a floating-point reduction variable, written as the loop counter, is common or worth much dedicated effort. I have seen this in real code, but it normally comes from people trying (perhaps too hard) to work around integer register pressure problems. The case that Elena presented, however:

> float fp_inc;
>
> float x = init;
> for (int i=0;i<N;i++){
> A[i] = x;
> x += fp_inc; // Loop invariant variable or constant
> }

is not uncommon. Being able to do something intelligent with this is worthwhile.

-Hal

> Thanks,
> Michael

> > -Hal
>

> > > Does it
> >
>
> > > have UB (in which case we can't hoist fastmath arithmetic) or is
> > > it
> >
>
> > > more like poison? Depending on the answer, for fastmath we can
> >
>
> > > considering doing what we do today for nuw/nsw (which has its own
> > > set
> >
>
> > > of issues, but at least wouldn't require us to start from
> > > scratch).
> >
>

> > > -- Sanjoy
> >
>
> > > _______________________________________________
> >
>
> > > LLVM Developers mailing list
> >
>
> > > llvm-dev at lists.llvm.org
> >
>
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>

> > --
>
> > Hal Finkel
>
> > Assistant Computational Scientist
>
> > Leadership Computing Facility
>
> > Argonne National Laboratory
>
> > _______________________________________________
>
> > LLVM Developers mailing list
>
> > llvm-dev at lists.llvm.org
>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
--

Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160516/d5c09f7a/attachment.html>
```

More information about the llvm-dev mailing list