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

[Tom Roeder]

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.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140326/e86ab92d/attachment.html>