llvm dev - Apr 2012 - [LLVMdev] some thoughts on the semantics of !fpmath

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

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.

Hi Dan,
> 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.
This was already violated by objc-specific metadata and if I get Chris
right - this is the intended behavior.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

> 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.)
Can it? My impression from the last discussion on alias analysis is
that a pass can drop metadata it doesn't know, but it cannot ignore
it, so GVN would have to drop the metadata in this case.
> Dan
>
Cheers,
Rafael

On Tue, 17 Apr 2012 08:38:18 -0400
Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> > 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.)
> 
> Can it? My impression from the last discussion on alias analysis is
> that a pass can drop metadata it doesn't know, but it cannot ignore
> it, so GVN would have to drop the metadata in this case.
I agree; I think that GVN should keep metadata that is the same and
drop metadata that differs. GVN might want to understand how to merge
certain kinds of metadata (line numbers in debug info?), but that is
not really necessary.

In reality, metadata might want to have merging rules and a defined API
so that metadata merging can be used by a number of passes
(vectorization will need this too). For example, merging fp-accuracy
data should choose the more-stringent bound, but not really be removed
all together.

 -Hal
> 
> > Dan
> >
> 
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory

On Apr 16, 2012, at 11:50 PM, Duncan Sands <baldrick at free.fr> wrote:
> 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.
Here's an example:

  %z = fadd float %x, %y, !fpmath !{ float 1000.0 }
  %p = fcmp ogt %z, 0.0
  br i1 %p, label %true, label %false
true:
  %d = call float @llvm.sqrt.f32(float %z)

This ought to be safe, since no matter now imprecise the fadd is,
the compare and branch protects the sqrt.

Now suppose a metadata-unaware optimizer can do value-range analysis
and can prove that the fadd always produces a positive finite value.
Then it's safe to replace the fcmp with true and delete the branch.

Then a metadata-aware codegen translates the fadd with reduced
precision, as permitted by the metadata. At runtime, the fadd may
return a negative value sometimes, because that could well be within
1000.0 ULPs of an expected non-negative result. But the branch is
now gone, and undefined behavior sqrts out.

Dan

On Apr 17, 2012, at 12:58 AM, Anton Korobeynikov <anton at
korobeynikov.info> wrote:
> Hi Dan,
Hi Anton,
>> 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.
> This was already violated by objc-specific metadata
Well, ObjC violates a lot more of LLVM IR semantics than just metadata.
Whether this is a problem or not depends on your perspective, I guess.
> and if I get Chris
> right - this is the intended behavior.

In Chris' own blog post on the subject [0], the first design
goal of metadata is that:

"Optimizations shouldn't be affected by metadata unless they explicitly
try to look at it."

Now, it is debatable whether this is actually feasible. Maybe it
is too restrictive, and that it would be better to just require
every pass and every backend to be aware of every kind of
officially recognized metadata, as needed. It seems that several
people are starting to think this way.

[0] http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html

Dan