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

[Duncan P. N. Exon Smith]

> On 2015-Mar-17, at 11:45, 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 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 agree that file scope inline asm doesn't sense for 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/