Bill Wendling
2012-Apr-30 01:25 UTC
[LLVMdev] [cfe-dev] [RFC] Encoding Compile Flags into the IR
On Apr 29, 2012, at 5:39 PM, Rafael Espíndola wrote:> On 29 April 2012 18: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. >> >> Goals >> ====>> >> My goals for whichever solution we come up with are to be: >> >> 1) Flexible enough to differentiate between flags which affect a module as a whole and those which affect individual functions. >> 2) Quick to query for specific flags. >> 3) Easily extensible, preferably without changing the IR for each new flag. >> >> Proposed Solution >> ================>> >> My solution to this is to use a mixture of module-level flags and named metadata. It gives us the flexibility asked for in (1), they are relatively quick to query (after being read in, the module flags could be placed into an efficient data structure), and can be extended by updating the LangRef.html doc. >> >> - Module-level flags would be used for those options which affect the whole module and which prevent two modules that do not have that flag set from being merged together. For example, `-msoft-float' changes the calling convention in the output file. Therefore, it's only useful if the whole program is compiled with it. It would be a module-level IR flag: >> >> !0 = metadata !{ i32 1, metadata !"-msoft-float", i1 true } >> !llvm.module.flags = !{ !0 } > > So the objective in here is to diagnose cases where the program would > already be broken even without LTO, correct? If so I think this going > on the right direction, I am just not sure if a 1:1 mapping with > command line options is the best solution. These are basic "abi > options". >Diagnosis is only one use of this proposal. The other, more important, use is to generate the correct code.>> - Named metadata would be used for those options which affect code generation for the functions, but which doesn't prevent two modules from being merged together. For example, `-fomit-frame-pointer' applies to individual functions, but it doesn't prevent a module compiled with `-fno-omit-frame-pointer' from being merged with one compiled with `-fomit-frame-pointer'. We would use a named metadata flag: >> >> define void @foo () { ... } >> define double @bar(i32 %a) { ... } >> >> ; A list of the functions affected by `-fno-omit-frame-pointer' within the Module. >> !0 = metadata !{ void ()* @foo, double (i32)* @bar } >> !fno.omit.frame.pointer = !{ !0 } >> >> And so on. > > This part I am not so sure about. I fixed a similar problem for unwind > tables by adding an attribute. It could be safely done with a metadata > with the oposite meaning (nouwtable). The things I am uncomfortable > with this part of the proposal are: > > * Why not use metadata attached directly to the functions? They are > the closest thing to an easy to add attribute. >Possible, but the problem with metadata is that it should be possible to remove them from the object and not affect the semantics of the program.> * The recent discussion about metadata points out that it is not > really safe to add information that only part of the compiler reasons > about. Metadata adds the nice property that it is safe to drop, but > that is it. Passes have to know about it, it should be documented in > the language ref and the verifier should check it. I am afraid that > this part of the proposal would again create a feeling that we have a > magic bullet for passing semantic info from the FE to some passes. >I'm not sure I understand your meaning here. The point of making this named metadata is that it cannot be stripped from the module via normal methods. And it's inevitable that we will need for passes to know about the metadata and modify their behavior accordingly. That's the whole point, of course. :) (They will, at least, be able to query the Module object for the information they care about. The Module is the one which knows about the metadata.)> * As you mention, this is probably the tip of the iceberg. Maybe we > should explore it a bit more with the tools we have before declaring > them insufficient. Duncan is working on fp precision, you can probably > add a no_frame_pointer metadata to functions and from there we will > have a better idea of how things are going. >I'd rather not start coding before we can agree on a concrete implementation. -bw
Rafael Espíndola
2012-Apr-30 01:43 UTC
[LLVMdev] [cfe-dev] [RFC] Encoding Compile Flags into the IR
>> * The recent discussion about metadata points out that it is not >> really safe to add information that only part of the compiler reasons >> about. Metadata adds the nice property that it is safe to drop, but >> that is it. Passes have to know about it, it should be documented in >> the language ref and the verifier should check it. I am afraid that >> this part of the proposal would again create a feeling that we have a >> magic bullet for passing semantic info from the FE to some passes. >> > I'm not sure I understand your meaning here. The point of making this named metadata is that it cannot be stripped from the module via normal methods. And it's inevitable that we will need for passes to know about the metadata and modify their behavior accordingly. That's the whole point, of course. :) (They will, at least, be able to query the Module object for the information they care about. The Module is the one which knows about the metadata.)My point is that many passes might need to know about it, not just the pass doing the modification. Any change to the IR has that property, so it is better that it stays a somewhat formal process, involving a discussion of each change and documentation on the language reference.. A simple example of a problem it would be nice to handle in LTO: A single file in a project is compiled with -mavx and the project uses cpuid to decide if it should use that function or not. With LTO currently we would miss the information that functions from one file could use AVX. Faced with this problem and with the above scheme implemented, it is very likely I would jump to recording -mavx in the IL. A more conventional review of an instruction_set metadata or attribute would be way more likely to find and document issues like: can the inliner inline a function into one having a more restrictive instruction set? What about the other way? What should the resulting instruction set be? It is unlikely the answer would be to just ignore the attribute. In summary, I like the current review and discussion process that goes with proposed changes to the IL and I am afraid the second part of the proposal would cause us to loose (not lose) it.> > -bw >Cheers, Rafael
Renato Golin
2012-Apr-30 07:46 UTC
[LLVMdev] [cfe-dev] [RFC] Encoding Compile Flags into the IR
On 30 April 2012 02:43, Rafael Espíndola <rafael.espindola at gmail.com> wrote:> My point is that many passes might need to know about it, not just the > pass doing the modification.Another reason to have a definite API for metadata in the IR. So passes shouldn't have to know about this particular metadata, but metadata in general. -- cheers, --renato http://systemcall.org/
Reasonably Related Threads
- [LLVMdev] [cfe-dev] [RFC] Encoding Compile Flags into the IR
- [LLVMdev] [cfe-dev] [RFC] Encoding Compile Flags into the IR
- [LLVMdev] [cfe-dev] [RFC] Encoding Compile Flags into the IR
- [LLVMdev] [cfe-dev] [Proposal] function attribute to reduce emission of vzeroupper instructions
- [LLVMdev] [RFC] Encoding Compile Flags into the IR