[LLVMdev] some thoughts on the semantics of !fpmath

[Hal Finkel]

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