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

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

> 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.
> -Eli
Cheers,
Rafael

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?

-Eli