[LLVMdev] some thoughts on the semantics of !fpmath

[Hal Finkel]

On Tue, 17 Apr 2012 11:53:25 -0700
Eli Friedman <eli.friedman at gmail.com> wrote:

> On Tue, Apr 17, 2012 at 11:29 AM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
> >> 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.
> >
> > I am also not sure if it is at all possible to design a metadata
> > system that allows passes to ignore it. I don't think that is true
> > for any metadata we have other than debug info (if you don't
> > consider broken debug info).
> >
> > IMHO the advantage that is still left in using metadata is that it
> > is easier to implement gradually, since passes are allowed to drop
> > it.
> >
> > Without metadata, changing the IL is an atomic operation where every
> > pass has to be audited for correctness. If we insist that passes
> > must drop metadata that they don't know about, support can be added
> > one pass at a time.
> 
> Okay... that could make sense.  So under this system, each pass would
> declare what kinds of metadata it supports, and the PassManager would
> automatically drop all other instruction-level metadata from the
> current module/function/loop?

For a transformation pass, should we do this only if the pass actually
changed something?

 -Hal

> 
> -Eli
> 
> _______________________________________________
> 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