[LLVMdev] [RFC] Encoding Compile Flags into the IR

[Bill Wendling]

On May 1, 2012, at 1:09 AM, Renato Golin wrote:

>> Could you give an example of how yours would look like in a sample Module?
> 
> Something similar to yours:
> 
> !llvm.module.flags.lto = !{ !0, !1 }
> !llvm.module.flags.cg = !{ !0 }
> 
> !0 = metadata !{ i32 1, metadata !"soft-float", i1 true } // forcing
> soft float all the way through
> !1 = metadata !{ i32 1, metadata !"VFPv2", i1 false } // The user do
> not want VFPv2 at all costs
> 
> 
> My proposal is more than just what it looks like in the IR, I don't
> really care that much about that.
> 
> My points:
> 1. Dropping general info into metadata is not enough. You need to
> make sure it'll be semantically correct for the majority of cases,

I don't know why you think I'm suggesting otherwise or ignoring this.

> 2. There will be more than one producer (compilation options, linker
> options, ABIs, ISAs) and more than one consumer (lto, cg, etc), you
> need to common up as much as possible, and split when the semantics
> differ,
> 3. You need rules for merging metadata, and that's not just a
> requirement of this topic, but also raised in the FP discussion,
> 4. Metadata must have its status raised in IR, and passes should be
> aware of it and manipulate it correctly.
> 
> Points 3 and 4 go against the original design of Metadata, I know. But
> it's being used by debug information and correctness (ARC, Obj-C).
> We're about to take the leap towards FP correctness with metadata, I
> don't think you can still disregard Metadata as quickly as the current
> back-end does.
> 
> Metadata semantics is much simpler than IR semantics. Most of the
> problems arise from merging code, so if there is a clear
> identification of the types of metadata (debug, asm, fp) and there is
> a simple module with simple, clear rules of merging, you can just
> apply those rules, via the same module. So passes don't need to learn
> too much, just blindly applying the general rules will get you far
> enough.
> 
> Merging metadata is (mostly) a matter of dominance and equivalence.
> When inlining a function into a different module, for instance, you'll
> check for the debug metadata in the former for equivalent (you define
> what's equivalent for each case) metadata and move the pointers. So,
> for "int a", you will still point "a" to the type "int" in the new
> module. In the FP case, you merge according to dominance: merging a
> less strict model into a more strict can either increase the strength
> of the former, or leave it be in a per-instruction model. That also
> depends on the architecture, and possibly, compiler flags.
> 
> My final point is simple: if you don't think about those issues now,
> before start filling IR with unchecked metadata, it'll be harder to
> enforce the required merge rules later. And they will be necessary.
> 
Okay. For some reason you think I haven't thought of these issues. Please don't make that assumption. I proposed a simple framework for conveying the information that needs to be conveyed. I omitted the types of information that's to be conveyed (except for a couple of examples) because that's a very different discussion than this, and requires much more detail (as you mentioned above). I'm concerned with figuring out how to do it at this point in time. Each flag that's passed down will need to be treated in its own special manner.

-bw