Hi Elena,

At this point we're really waiting on responses to the following three

questions:

# Why is it worth aggressively optimizing floating pointer induction variables?

By "floating point induction variable" I'm referring to "for (float i

= 0.0; i < F; i += 1.0)", not "for (int i = 0 to N) x += 5.0". If

you're mainly interested in the latter, IMO the SCEV changes are

overkill -- we should just pattern match floating point reductions

outside of SCEV.

So far the only response I've seen is "ideally we'd like to vectorize

even if the induction variable is in floating point", and while I

agree with the sentiment (obviously, all else being equal, I'd like

LLVM to be as effective as possible), to justify this large a change

we'd need a compelling argument why such cases (loops with floating

point controlling induction variables) are interesting optimization

targets. Are

there real world program that have this kind of behavior?

I also think you're underestimating how complex the change is. It may

look simple now, but this will add significant cognitive overhead

moving forward, more so not because we're adding "one more" type, but

because we're going from "only one type" to "two types".

E.g. getRange() will be invalid over half the SCEV kinds, unless we

add a new ConstantFPRange class.

# How far can we get without teaching SCEV about floating point at all?

If you do have a set of applications that do rely on floating point

induction variables, how far can you push them by transforming the

floating point induction variables to integer induction variables?

This should have significantly less surface area than the FP-SCEV

changes and if it is enough, then we should prefer it over FP-SCEV.

OTOH if you have interesting use-cases that *cannot* be resolved by

the transform above, then that's a good case for moving FP-SCEV

forward.

# What things are you depending on to have the SCEVs accurately

represent FP semantics?

I think you at least need associativity, to be able to use SCEV's

canonicalization of N-ary expressions over the possible ordering of

operands. Given you want to do trip count computations, then you

probably also need "A + X != X" for X != 0.0.

Are fast-math flags enough for this?

(I typed this in before reading

https://llvm.org/bugs/show_bug.cgi?id=27894#c7 , Hal has answered the

question there).

And as Andy said, we'd need to circle in a floating point expert into

the review.

-- Sanjoy