This is a continuation of adding FMF to call instructions:
http://reviews.llvm.org/rL255555
As with D15937, the intent of the patch is to preserve the current behavior of the transform except that we use the pow call's 'fast' attribute as a trigger rather than a function-level attribute.
But this raises a possible improvement noted by the TODO comment:
Should all of the new instructions be marked 'fast' since they were derived from a fast pow()? I think a user of -ffast-math would expect that despite the potentially increased risk of numerical disaster. In particular, the possible 'fdiv' would benefit from being turned into a reciprocal estimate on a target that supports that. There's probably less risk/opportunity to do anything with the chain of dependent multiplies, but if we're going 'fast', we might as well flag them all?