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

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

> 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?
I didn't think about using the pass manager, but that would be a way to do
it.
> -Eli
Cheers,
Rafael

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

> For a transformation pass, should we do this only if the pass actually
> changed something?
In the pass manager? That is interesting. What I had in mind was just
changing the passes to only copy the metadata info they know about.
The problem is that in examples like the one Dan created. The pass
would have to delete metadata in an instruction it reasoned about but
didn't otherwise modify, which is fairly error prone.
>  -Hal
Cheers,
Rafael

Hi,
>> 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?
what?!  This seems like huge overkill to me.  As far as I can see main problem
currently is that some passes *add* metadata to instructions that didn't
have
any.  That's one way of viewing the problem with GVN: it can take an
instruction A without metadata and identify it with an instruction B with
metadata, so in effect GVN has added metadata to A.  Any pass that blatantly
went around adding random metadata (eg: tbaa metadata) to instructions would be
considered to be obviously buggy.  I think GVN and EarlyCSE or whoever should
be fixed not to do this, or rather to tag the unified instruction with the
least common denominator of the metadata on the original instructions (and thus
in effect it will only ever drop metadata rather than adding it).

Ciao, Duncan.

On Wed, 18 Apr 2012 09:35:33 +0200
Duncan Sands <baldrick at free.fr> wrote:
> Hi,
> 
> >> 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?
> 
> what?!  This seems like huge overkill to me.  As far as I can see
> main problem currently is that some passes *add* metadata to
> instructions that didn't have any.  That's one way of viewing the
> problem with GVN: it can take an instruction A without metadata and
> identify it with an instruction B with metadata, so in effect GVN has
> added metadata to A.  Any pass that blatantly went around adding
> random metadata (eg: tbaa metadata) to instructions would be
> considered to be obviously buggy.  I think GVN and EarlyCSE or
> whoever should be fixed not to do this, or rather to tag the unified
> instruction with the least common denominator of the metadata on the
> original instructions (and thus in effect it will only ever drop
> metadata rather than adding it).
This makes sense to me. Does anyone have a counterexample? And this is
exactly why I think we should have a mergeMetadata API -- I need this for the
vectorization passes as well.

 -Hal
> 
> Ciao, Duncan.
> _______________________________________________
> 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