Hello,
Please review the trivial fixes in 4 different optimizations
that occasionally/wrongly lost FastMathFlags in FP operations.
I have more fixes for many cases in InstCombiner module,
but those are a bit more difficult and should be submitted for code-review separately.
Also, I added the developers, whose lines I changed, to the Subscribers list. (I used svn blame to get that list).
Thanks you,
Vyacheslav Klochkov
lib/Transforms/Scalar/GVN.cpp
Before GVN: t1 = <fast> a+b store t1 to [mem1] ... t2 = load [mem1] use t2 After GVN: t1 = a+b // this operation must remain the <fast> flags! store t1 to [mem1] ... use t1 instead of original use of t2 (where t2=load from [mem1]). The uses of t2 were replaced by uses of t1. Unfortunately, both t1 and t2 can be cast to <FPMathOperator> (the load could be cast as well because the resulf of load was FP), but here it is clear that math-flags of t1 and t2 should NOT be AND-ed.
lib/Transforms/Scalar/Reassociate.cpp
Before: ((a*b)*c)*d // all MUL operations have <fast> math flags. After: (a*b)*(c*d) // all MUL operations lost <fast> math flags.
lib/Transforms/Vectorize/SLPVectorizer.cpp
FastMath flags were not propagated to a newly created FCmp operation.
lib/CodeGen/CodeGenPrepare.cpp
FastMath flags were not propagated to a newly created FCmp operation.
This would be more obvious if you did: Builder.setFastMathFlags(cast<FPMathOperator>(I)->getFastMathFlags())