[llvm-dev] Working on FP SCEV Analysis

[Chandler Carruth via llvm-dev]

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 well?  (I haven't
>   worked on our vectorizers so pardon the possibly stupid question)
>   in the example you gave, why do you need SCEV to analyze the
>   increment to vectorize the loop (i.e how does it help)?  What are
>   some other concrete cases you'll want to optimize?
>
>
> Graphics shading languages like GLSL or HLSL have floating point types as
> the “default” types.  Integers weren’t even added until later revisions of
> GLSL.  In that world, it’s not especially strange to imagine a loop counter
> written in floating point.
>

But most of those are convertible to integer IVs which as Andy pointed out
up the thread is something IndVarSimplify tries to do.

A potential way to show a motivating use case is what Andy already
outlined: cases where non-integer values are fundamentally used as part of
the IV.

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 relax IEEE semantics so this looks like
normal algabra etc:

  for (float f = 0.01f; f < 1.0f; f += 0.01f)
    ...

I'd rather see us cleverly turn it into:

  float f = 0.01f;
  for (int i = 1; i < 100; i += 1, f += 0.01f)
    ...

(or whatever the transform would be, I've not spent lots of time thinking
about the exact way to map this onto a synthetic "adding that value N times
crosses threshold, so let's replace IV with a counter to N")

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160518/7814064d/attachment.html>