<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 25, 2014 at 5:23 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
On Mar 25, 2014, at 12:06 AM, Nick Lewycky <<a href="mailto:nicholas@mxc.ca">nicholas@mxc.ca</a>> wrote:<br>
<br>
> Nick Kledzik wrote:<br>
>><br>
>> On Mar 24, 2014, at 4:27 PM, Tom Roeder<<a href="mailto:tmroeder@google.com">tmroeder@google.com</a>>  wrote:<br>
>>> The small patch attached here adds support for an -mattr option to the<br>
>>> gold plugin and to llvm-lto. This allows the caller to specify details<br>
>>> of the subtarget architecture, like +aes, or +ssse3 on x86.  Note that<br>
>>> this required a change to the include/llvm-c/lto.h interface: it adds<br>
>>> a function lto_codegen_set_attr and it increments the version of the<br>
>>> interface.<br>
>>><br>
>>> Please let me know what you think.<br>
>><br>
>> The LTO API already has:<br>
>>    lto_codegen_debug_option(lto_codegen_t, const char *);<br>
>><br>
>> Could you support -mattr options using the existing API like?:<br>
>>     lto_codegen_debug_option(cg, “-mattr=+sse3”);<br>
><br>
> 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.<br>
</div>It is in the public header <llvm-c/lto.h>.  How can it not be part of the public interface?<br>
<div class=""><br>
<br>
> 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.<br>


><br>
> 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.<br>
</div>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.<br>

</blockquote><div><br></div><div>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?</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I understand that a string interface by-passes any sort of static analysis.<br>
<br>
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?<br>

</blockquote><div><br></div><div>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.</div>

<div><br></div><div>Tom</div><div> </div></div></div></div>