> On 2015-Mar-17, at 11:45, Akira Hatanaka <[email protected]> wrote: > > On Mon, Mar 16, 2015 at 2:14 PM, Eric Christopher <[email protected]> wrote: > > > On Mon, Mar 16, 2015 at 8:27 AM Akira Hatanaka <[email protected]> wrote: > On Fri, Mar 13, 2015 at 4:09 PM, Eric Christopher <[email protected]> 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/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
