[cfe-dev] [LLVMdev] [RFC] Encoding Compile Flags into the IR

[Renato Golin]

On 1 May 2012 00:10, Bill Wendling <wendling at apple.com> wrote:
> I'm not familiar with the fp-math thread. Could you summarize it for me?

Too many issues to summarize:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-April/048951.html

The important bit to this discussion is that metadata should be used
for correctness and we shouldn't disregard it the way we do today.


> The information is important for correct code generation and linking. I need alternatives to putting it in metadata. :)

What you need is to present the information to the code generation /
linking phases in a concise, de-duplicated and semantically correct
way.

Just dropping compilation flags on the IR will give you the
information, yes, but their meaning could be inaccurate. Compiling for
generic platforms than linking for specific CPUs could lead to
confusion, or slight changes in compilation options semantics could
make a very subtle corner case blow up (silently) in the linker.


> 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,
 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.

-- 
cheers,
--renato

http://systemcall.org/