[PATCH] Pass -mglobal-merge as a module flag metadata.

Akira Hatanaka ahatanak at gmail.com
Thu Mar 19 10:09:35 PDT 2015 

On Wed, Mar 18, 2015 at 12:04 AM, Eric Christopher <echristo at gmail.com>
wrote:

>
>
> On Tue, Mar 17, 2015 at 11:45 AM Akira Hatanaka <ahatanak at gmail.com>
> wrote:
>
>> On Mon, Mar 16, 2015 at 2:14 PM, Eric Christopher <echristo at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Mar 16, 2015 at 8:27 AM Akira Hatanaka <ahatanak at gmail.com>
>>> wrote:
>>>
>>>> On Fri, Mar 13, 2015 at 4:09 PM, Eric Christopher <echristo at gmail.com>
>>>> wrote:
>>>>
>>>>> No, you probably haven't. I was seeing it as clang doing to lto link
>>>>> of the module together and then codegen based on that (which means it would
>>>>> have the options), but...
>>>>>
>>>>> That said, I think the general problem is more specific. I.e. how do
>>>>> you specify -msse3 as part of the default code generation flags when you do
>>>>> lto?
>>>>>
>>>>>
>>>> In LTOCodeGenerator.cpp, SubtargetFeatures::getDefaultSubtargetFeatures
>>>> is called to get the default subtarget features and the string is passed to
>>>> TargetCreateTargetMachine.
>>>>
>>>> Is that what you are asking about?
>>>>
>>>
>>> Yes, but that code doesn't work in the abstract. It only works on darwin
>>> because it has hard coded values. The features there are only based on the
>>> triple so saying that you want to pass in a default of -msse3 to your code
>>> generator doesn't work unless you a) hard code a cpu into
>>> LTOCodeGenerator.cpp or, b) hard code it into the triple (x86_64h anyone?).
>>>
>>>
>> The commit message of r165809 explicitly states the code in
>> LTOCodeGenerator.cpp was committed as a temporary hack, so it should be
>> replaced with something else or removed to work on non-darwin platforms.
>>
>>
> I'm not too worried about this from the lto perspective. The rest of the
> code generation where the default features are different from the module
> ones will work with the clang patch that we talked about that encodes
> subtarget features on the functions. I apologize that I used -msse3 as my
> example, I think it sent the discussion down a poor path and not what I
> intended.
>
>
>> I see that getTargetCPU and getTargetFeatureString are called only in
>> AsmPrinter or its subclasses to create a default subtarget. I think in most
>> cases the default cpu can be determined by scanning all the target-cpu that
>> are stored as function attributes in the IR, but the algorithm to determine
>> it would be highly target specific.
>>
>>
> This wouldn't be such a good idea.
>
>
>> I'm not sure if it's correct to use a single "default" cpu or feature
>> string to assemble a module-level inline-asm. Suppose we compile two files
>> that have file-level inline assembly statements using different command
>> line options (different target cpu and features), link the IRs, and compile
>> the combined IR. In that case, shouldn't we be constructing two different
>> subtargets based on the command line options that were used to compile each
>> file instead of constructing a single "default" subtarget as we do now? Or
>> should we just drop support for file scope inline asm when we do function
>> multiversioning or LTO?
>>
>>
> Function multiversioning isn't relevant here, it involves per function
> code generation it's true, but shouldn't affect anything at the module
> level. I was more worried about:
>
> clang foo.c -emit-llvm -o foo.bc
> clang bar.c -emit-llvm -o bar.bc
> clang -msse3 foo.bc bar.bc -flto -o foo.x
>
> where the -msse3 would override the default triple on the architecture.
> It's probably not too big of a worry from the perspective of code
> generation, but rather seemed like something someone might do for lto (more
> on this in a bit).
>
> Largely I hate module level inline assembly, that said we should probably
> allow people to do weird things in LTO that they're allowed to do in normal
> code generation.
>
>

We might have to change the representation of module-level inline-asm in
the IR, if we are going to allow users to compile module-level inline-asm
statements in two different files using different command line options.
Currently, module-level inline-asm is just a concatenated string, so there
is no way to say which part of the inline-asm string is compiled with which
options.


> I'm talking about a case like this, where two files foo1.c and foo2.c are
>> compiled with LTO.
>>
>> $ clang -mips16 foo1.c -o foo1.bc -flto -c -target mipsel
>> $ clang foo2.c -o foo2.bc -flto -c -target mipsel
>> $ clang foo1.bc foo2.bc -o foo -flto -target mipsel
>>
>>
> Right, not too awful concerned here.
>
> Here though (and referencing Ahmed's other email), we're talking about
> passes being enabled via subtarget options in the default pipeline but can
> be turned off by a single -mno-global-merge in the pipeline somewhere? One
> of those reasons why I thought having such global options enabled by
> command line at lto time to be a better idea. The command line option side
> would still be handled by clang, it'd just be the interface via the linker
> that would need to be expanded to pass down code gen options. Also it
> avoids having every module pass that we want to turn on and off at lto time
> needing to be handled on a per module basis as well as being able to use
> the basic command line parsing to handle things like LTO -O1 or -Oz or -Os
> or -O3 -fno-vectorize ...
>
> Thoughts?
>
>
Does it mean that global-level options such as global-merge would be passed
at link time? Function level options such as -msse3 would be a compile time
option, is that correct?

$ clang foo.c -emit-llvm -o foo.bc -msse3
$ clang bar.c -emit-llvm -o bar.bc -msse3
$ clang -mno-global-merge foo.bc bar.bc -flto -o foo.x

-eric
>
>
>> -eric
>>>
>>>
>>>>
>>>>
>>>>> The C++ interface has addAttr (which is painful in that it requires,
>>>>> as you say, every linker to understand llvm's command line interface), but
>>>>> this is also pretty painful:
>>>>>
>>>>>   const void *compile(size_t *length,
>>>>>                       bool disableOpt,
>>>>>                       bool disableInline,
>>>>>                       bool disableGVNLoadPRE,
>>>>>                       bool disableVectorization,
>>>>>                       std::string &errMsg);
>>>>>
>>>>> because, you know, all optimizations, inlining, gvnloadpre, and
>>>>> vectorization are all anyone care about :)
>>>>>
>>>>> Realize this has dovetailed into "let's solve the general problem" but
>>>>> I am curious. The gold plugin's methods aren't much better.
>>>>>
>>>>> Or am I missing something?
>>>>>
>>>>> -eric
>>>>>
>>>>>
>>>>> http://reviews.llvm.org/D7968
>>>>>
>>>>> EMAIL PREFERENCES
>>>>>   http://reviews.llvm.org/settings/panel/emailpreferences/
>>>>>
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150319/464c9973/attachment.html>

More information about the cfe-commits mailing list