[PATCH] D20695: Floating Point SCEV Analysis

[Elena Demikhovsky via llvm-commits]

delena added a comment.

> I still stand by my earlier comment that we should do something like this as a last resort.


It is very convenient way to answer all questions about FP variables that being changed and used inside loop.


================
Comment at: ../include/llvm/Analysis/ScalarEvolutionExpressions.h:310
@@ +309,3 @@
+  ///
+  class SCEVFAddExpr : public SCEVCommutativeExpr {
+    friend class ScalarEvolution;
----------------
sanjoy wrote:
> What is the intent behind making `SCEVFAddExpr` and `SCEVFMulExpr` subclasses of `SCEVNAryExpr`?  Does `(a + b + c)` represent `((a + b) + c)` or `(a + (b + c))`?
I planned to use SCEVFAddExpr  and SCEVFMulExpr to couple FP calculations, like it is done for integer operations.
for example: a + const1 + b + const2 = a + b + const3 
or a * 0.0 = 0
If compiler supports FP reduction, it can support any FP simplification in this mode. I assume that fast-math should allow all these transformations.

================
Comment at: ../lib/Analysis/ScalarEvolution.cpp:1503
@@ +1502,3 @@
+      if (Start->getSCEVType() == scConstant) {
+        int64_t IntVal = cast<SCEVConstant>(Start)->getAPInt().getSExtValue();
+        StartFP = getFpConstant(Ty, (double)IntVal);
----------------
sanjoy wrote:
> Note: `getSExtValue` will assert for integers that are large than 64 bits.
I'll fix. thank you.

================
Comment at: ../lib/Analysis/ScalarEvolution.cpp:2875
@@ +2874,3 @@
+const SCEV *ScalarEvolution::getFMulExpr(SmallVectorImpl<const SCEV *> &Ops) {
+
+  assert(!Ops.empty() && "Cannot get empty mul!");
----------------
sanjoy wrote:
> This is all duplicated code.  If we go ahead with this, we should definitely common this with the integer version.
I thought about limitations in FP manipulations relatively to integer values. If fast-math allows all manipulations, we definitely can share the code. 


Repository:
  rL LLVM

http://reviews.llvm.org/D20695