[PATCH] Add an -mattr option to the gold plugin to support subtarget features in LTO

[Nick Kledzik]

On Mar 25, 2014, at 12:06 AM, Nick Lewycky <nicholas at mxc.ca> wrote:

> Nick Kledzik wrote:
>> 
>> On Mar 24, 2014, at 4:27 PM, Tom Roeder<tmroeder at google.com>  wrote:
>>> The small patch attached here adds support for an -mattr option to the
>>> gold plugin and to llvm-lto. This allows the caller to specify details
>>> of the subtarget architecture, like +aes, or +ssse3 on x86.  Note that
>>> this required a change to the include/llvm-c/lto.h interface: it adds
>>> a function lto_codegen_set_attr and it increments the version of the
>>> interface.
>>> 
>>> Please let me know what you think.
>> 
>> The LTO API already has:
>>    lto_codegen_debug_option(lto_codegen_t, const char *);
>> 
>> Could you support -mattr options using the existing API like?:
>>     lto_codegen_debug_option(cg, “-mattr=+sse3”);
> 
> Absolutely not. That API has the word "debug" in its name because it is strictly reserved for debugging libLTO. That means that it is not part of libLTO's public interface.
It is in the public header <llvm-c/lto.h>.  How can it not be part of the public interface?  


> The reason is that libLTO has a strong ABI requirement. Once we have a user using libLTO, we can never ever break them at the ABI level. The intention is that this exposed interface is something small that we can audit, and that we can change LLVM's innards without disturbing libLTO.
> 
> Once you allow passing arbitrary flags across, every single flag everywhere in every llvm library becomes part of the permanent ABI that can never be changed.
That boat has already sailed.  The darwin linker accepts “-mllvm foo” and calls lto_codegen_debug_option(xx, “foo”). It has been used with things like -mcpu=blah to work around that information not being recorded in the bitcode files.

I understand that a string interface by-passes any sort of static analysis.  

Isn’t the long term goal that info like +sse3 be recorded in bit code files so that these options are not needed at link time?  If so, then the proposed API is a short term work around.  My point is that we already have a hack to pass arbitrary option strings.  Why have two?

-Nick