[LLVMdev] some thoughts on the semantics of !fpmath

Duncan Sands baldrick at free.fr
Mon Apr 16 23:50:51 PDT 2012


Hi Dan,

> 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.

I don't understand how it can not be safe: if the metadata is dropped
then the optimizers have to be more strict, thus it is safe.

> 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.)

This is true, what do you suggest as a solution?

> 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.

I think something like this is inevitable in any system that allows fast math.

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

Yes, this bothers me too.  I've CC'd Peter since he added the definition.

Ciao, Duncan.



More information about the llvm-dev mailing list