On Wed, Mar 18, 2015 at 12:04 AM, Eric Christopher <[email protected]> wrote:
> > > On Tue, Mar 17, 2015 at 11:45 AM 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'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/ >>>>> >>>>> >>>>>
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
