[LLVMdev] some thoughts on the semantics of !fpmath

Duncan Sands baldrick at free.fr
Wed Apr 18 00:35:33 PDT 2012


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.



More information about the llvm-dev mailing list