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

[Renato Golin]

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.

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.

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.

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.

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

-- 
cheers,
--renato

http://systemcall.org/