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
Rafael Espíndola
2012-Apr-17 18:57 UTC
[LLVMdev] some thoughts on the semantics of !fpmath
> 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.> -EliCheers, 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
Rafael Espíndola
2012-Apr-17 19:07 UTC
[LLVMdev] some thoughts on the semantics of !fpmath
> 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.> -HalCheers, 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