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

[Akira Hatanaka]

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

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?

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

-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/20150317/1427ce3b/attachment.html>