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

[Eric Christopher]

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.


> 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?

-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/20150318/c923aed0/attachment.html>