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

[Bill Wendling]

On Apr 30, 2012, at 1:03 AM, Renato Golin wrote:

> On 29 April 2012 23:44, Bill Wendling <wendling at apple.com> wrote:
>> Hi,
>> 
>> Link-Time Optimization has a problem. We need to preserve some of the flags with which the modules were compiled so that the semantics of the resulting program are correct. For example, a module compiled with `-msoft-float' should use library calls for floating point. And that's only the tip of the proverbial iceberg.
> 
> Hi Bill,
> 
> While it's true that knowing compiler flags will help you with linking
> problems (including optimisations), I don't think they're 1:1 with
> link issues, nor I think storing all compilation options on all
> modules every time is a fair price to pay for something that specific.
> 
> You have a goal to correct link-time optimisations, or as we discussed
> earlier in the fp-math thread, even code generation could be broken
> without the knowledge of the user's intent. That can be accomplished
> now by putting "-msoft-float" as a global metadata, yes, but does that
> fit a general solution for the general problem? I literally don't
> know.
> 
I'm not familiar with the fp-math thread. Could you summarize it for me?

> What you need to do, if your intent to create a long-lasting framework
> - not just a quick fix for the LTO, is to analyse the biggest problems
> and the information you need. If you have problems in multiple domains
> (I'm guessing fp is not the only one), and could get information from
> multiple sources (again, guessing compile options is not the only
> one), then your solution is lacking.
> 
Nothing about the proposal is meant to be a quick fix. The process of adding new flags that we care about would be a formal process, just not one that modifies the IR every time. (Yes, I'm fixated on that one aspect of it. I find it too heavyweight for the problem at hand.)

> I'm guessing linker scripts could have a lot to say about link-time
> issues, as well as environment, ABI, chipset, ISA and so on. If you
> put all compiler flags in metadata now, we'll end up putting all
> options of all sources in global metadata, and well, that's far from
> desirable.
> 
The information is important for correct code generation and linking. I need alternatives to putting it in metadata. :)

> I propose a more general scheme of global metadata, similar to yours
> (one global for each big problem, multiple options inside for each
> user intent), but generated from cherry-picked sources and put into
> specific global metadata baskets (duplication could occur, if the
> semantics is different). So each further step reads its own basket
> (LTO reads @llvm.metadata.lto {...}) and so on. Of course LTO could
> read other baskets, but it'll have to be for a precise reason, with a
> precise meaning.
> 
> While merging modules (inlining included) with different metadata, you
> have to have a specific well defined merge rule, with warnings and
> errors in case they mismatch. We were discussing the merge semantics
> for fp models earlier, that kind of analysis should happen for every
> new flag you put in.
> 
Yup! The module-level flags has these abilities. :-)

> Though you have to take my proposal with a pinch of salt, because
> that's remarkably similar to ARM's build attributes, and I'm not sure
> that's the best idea either. There is probably a smarter way of doing
> this, I just didn't think hard enough to find it... ;)
> 
> But either way, you will need some sort of guidelines on how passes
> should treat metadata with stronger guarantees than today, or your LTO
> will still not see the info it needs...
> 

Could you give an example of how yours would look like in a sample Module?

-bw