[LLVMdev] some thoughts on the semantics of !fpmath

[Dan Gohman]

I realize that some of these thoughts apply equally to the
prior !fpaccuracy metadata that's been around a while, but I
hadn't looked at it closely until now.

The !fpmath metadata violates the original spirit of
metadata, which is that metadata is only supposed to exclude
possible runtime conditions, rather than to introduce new
possible runtime possibilities. The motivation for this is
that optimizers that ignore metadata should always be safe.
With !fpmath, theoretically there are ways this can fail.

It also has the problem that there's nothing preventing a
pass like GVN from merging a !fpmath-decorated operation with an
undecorated operation, and nothing requiring it to strip
the !fpmath tag when it does so. (This is a general problem
with LLVM metadata semantics.)

The current definition of !fpmath does not appear to require
operations to return the same result each time they are
evaluated. This fits with the way the optimizer works, because
optimizations like inlining can duplicate code, and it's
impractical to guarantee that each instance of a duplicated
instruction will be subsequently optimized in the same way.
However, what's not obvious is that this implies that
operations tagged with !fpmath actually return values that are
effectively constrained undef. That's interesting, though it's
not actually fundamentally new, since constrained undef is
already a fairly well established concept in LLVM.

The current definition of !fpmath does not specify whether
the ULPs refers to error with respect to infinitely precise
results or rounded results.

Dan