[LLVMdev] Embedding cpu and feature strings into IR and enabling switching subtarget on a per function basis

Duncan P. N. Exon Smith dexonsmith at apple.com
Tue Jan 27 07:49:19 PST 2015


> On 2015 Jan 27, at 00:37, Eric Christopher <echristo at gmail.com> wrote:
> 
> 
> 
> On Tue Jan 27 2015 at 12:31:20 AM Chandler Carruth <chandlerc at google.com> wrote:
> 
> On Mon, Jan 26, 2015 at 9:53 PM, Eric Christopher <echristo at gmail.com> wrote:
> As I said in my first email perhaps the TTI->FTTI transition is a good place to start working here without having to worry much about redoing huge swaths of llvm.
> 
> FWIW, TTI is next on my hit list for porting to the new pass manager. In order to work in that world, the entire thing needs to be simplified to not be an analysis group and it needs to be split into per-module TTI and per-function TTI. I'm working on this *right now*, but let me know if there is some other change you would like to see incorporated into this.
> 
> No, this sounds great. Another place to work right now that would see some good code cleanup is the LTOCodeGeneration stuff. There's a use of the subtarget there that's not going to be safe and so the entire thing around accumulating and sorting all of the library calls needs to be rethought and rewritten.

BTW, this code here is preventing LTO from "internalizing" user-provided
replacements for C library functions, since otherwise optimizations will
gut and/or delete them (and then later lower calls to them).

We need to figure out a (conservative) list up-front of which user-provided
library function replacements will be needed later.  One obvious option is
to blacklist internalizing library function replacements in *all*
subtargets (similar to this code, but visit all subtargets instead of the
"main" one).

You can see the original discussion in the archives [1][2].

[1]: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131104/193828.html
[2]: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131104/193977.html



More information about the llvm-dev mailing list