[PATCH] D116952: [ConstantFolding] Flush folded denormals to zero when using fastmath

[David Candler via Phabricator via llvm-commits]

dcandler added a comment.

Thanks for taking a look, it does appear I misunderstood a few things.

The original motivation was that downstream we found a case where the output of the compiled program is different between `O0` and `O1`: at `O0` a floating point instruction executes on the target and produces a zero, but at `O1` the instruction gets constant folded to a denormal value. So I have been exploring whether it would be possible to handle denormals at the time of folding, since this occurs before other combination passes (e.g DAGCombiner).

The `denormal-fp-math` attribute does contains the relevant information about the floating point envionment, and should already be accessible during folding via the instruction pointer (assuming it belongs to a function at the time). So I believe I could potentially rework this to avoid pulling in target info by checking `denormal-fp-math` instead, if that would be more acceptable. Reading the language reference, the attribute doesn't mandate flushing denormals to zero, but does suggest inputs should be treated as zero, which constant folding also does not currently respect. On testing, this can lead to similar differences in ouput when folding a floating point instruction where one input is a denormal, so it may make sense to check the inputs as well as the output in `ConstantFoldInstOperands`.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116952/new/

https://reviews.llvm.org/D116952