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

[Tom Roeder]

On Wed, Mar 26, 2014 at 9:19 AM, Tom Roeder <tmroeder at google.com> wrote:

> On Tue, Mar 25, 2014 at 5:23 PM, Nick Kledzik <kledzik at apple.com> wrote:
>
>>
>> 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.
>>
>
> That's interesting; it looks to me like mcpu is supported directly in
> gold: see tools/gold/gold-plugin.cpp, where it looks for the string mcpu=
> and passes that down to lto to set the CPU. Why is the other interface
> being used for it instead?
>
>
>>
>> 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?
>>
>
> The goal here is not to support arbitrary option strings. The patch as
> proposed exposes the existing -mattr flag from LLVM (from
> include/llvm/CodeGen/CommandFlags.h). Anything passed there will be checked
> by SubtargetFeatures and will trigger a warning if it's not a valid option
> for the given target.
>

Forgot to say: and while the lto method I've added does take an arbitrary
string, it's subject to those same constraints: the string must be a valid
feature for the target.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140326/87b8359f/attachment.html>