[LLVMdev] [RFC] Storing default function attributes on the module
echristo at gmail.com
Wed Mar 11 13:10:12 PDT 2015
On Wed, Mar 11, 2015 at 1:08 PM Rafael Espíndola <rafael.espindola at gmail.com>
> > 4. Having `llc` mutate the IR itself -- the obvious solution, which
> > Akira posted a patch for a few months ago -- does the job just as
> > well as `llvm-attr-mutate` but with a much cleaner interface. It
> > fails to distinguish between target defaults and explicit
> > attributes, but when combined with `llvm-extract`, it gives you full
> > control over the codegen options for each function.
> > Remind me again why we don't just do #4? It seems like the simplest way
> > to keep `llc` viable in the short term.
> > llc should be able to override the default values for options without
> > mutating anything that’s explicitly specified at a function (or module)
> > level.
> > For example, if I have a .ll file with specialized functions with
> > CPUs specified, I want to be able to recompile that file with -mcpu= on
> > llc command line in such a way that those functions don’t get changed,
> > any functions that don’t have an explicit CPU on them do. Consider
> trying to
> > test something like function multi versioning.
> Sure, but that can be implemented with 4, no? Something like:
> * In llc, if given -mcpu:
> * Iterate over all functions:
> * If a function has a an explicit cpu, leave it alone.
> * If a function has no explicit cpu, set it to the -mcpu command line
The problem with some of this is that we could see a lot of default cpus on
functions. I.e. it may be set most of the time. That's still up in the air
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev