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

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

2012/4/17 Hal Finkel <hfinkel at anl.gov>:
> 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.
+1!

The original intent of metadata was to represent spurious concepts,
and the design was that is was always safe to ignore more to avoid the
complex semantics than specific intent.

Debug data should never be discarded if the user specified -g. It can
be merged, changed, but never discarded. Otherwise, what's the point?

Vectorisation the same, if you do some transformation based on one
information and need a subsequent pass to finish the same
transformation, and you destroy the metadata, you get incorrect
results.

With FP precision, you might be able to use different instructions or
ignore specific traps on more relaxed models, and the back-end can
only know that if you kept the metadata until the end.

I appreciate the cost of strict metadata semantics to the IR, but I
think we're at a point that either we use a decent metadata engine or
none at all.

-- 
cheers,
--renato

http://systemcall.org/

On Tue, Apr 17, 2012 at 9:16 AM, Renato Golin <rengolin at systemcall.org>
wrote:
> With FP precision, you might be able to use different instructions or
> ignore specific traps on more relaxed models, and the back-end can
> only know that if you kept the metadata until the end.
>
> I appreciate the cost of strict metadata semantics to the IR, but I
> think we're at a point that either we use a decent metadata engine or
> none at all.
The point isn't whether it's a good idea to discard FP precision data
(or vectorization data, or debug data), but rather whether IR
transformations are allowed to treat a meta-data annotated instruction
as having the same semantics as an unannotated instruction.  If
transformation passes which aren't metadata aware aren't allowed to
reason about an annotated instruction, there's no point to metadata in
the first place: we can just introduce new intrinsics/instructions, or
change the definition of an existing instruction/intrinsic.

-Eli