[llvm-dev] Floating Point SCEV Analysis

[Demikhovsky, Elena via llvm-dev]

   >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.

[Demikhovsky, Elena] Pattern match for "for (int i = 0 to N) x += 5.0" may be not so difficult. 
But you can't cover everything with patterns, for example:
for (int i = 0 to N) {
  x += 5.0
  y = (float)i * 0.5 + z
  A[i] = x + y
}  
This loop is resolved with FP_SCEV. You can say that FP SCEV is too powerful for this small task, but it is using the *existing* algorithm.
I don't need to invent anything for the *recurrent* calculation of (x+y). SCEV allows to estimate behavior of FP value inside loop - I mean isLoopInvariant() at least.

Conversion of  " for (int i = 0 to N) x += 5.0 " to 5.0*N is also very convenient with FP SCEV. (Let's assume that we let this transformation in some mode) 
Just because we do not need to implement anything new. The engine is already exists.
 
>  Are there real world program that have this kind of behavior?
[Demikhovsky, Elena] As Hideki said, fortran applications are FP IV based. I can't say how easy to map FP IV to integer.

   >
   >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.

[Demikhovsky, Elena] I have primary implementation of ConstantFPRange, but I don't want to upload it now.
The first patch is for the *secondary* FP IV only.


 [Demikhovsky, Elena] I have a question - will you allow implementation of FP SCEV for secondary IVs only and use it for recurrence, like in 2 examples above?
Let it will be restricted and not as powerful as integer on this stage. I'll limit transformations that can be done with FP SCEV.
 It is still better than "pattern match" in order to vectorize loops with FP variables. 
Do you see other than "pattern match" solution that will work like FP SCEV for FP variables? 

Thank you.
- Elena
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.