[PATCH] D45225: [WIP] Add IR function attributes to represent codegen optimization level

[Eli Friedman via Phabricator via llvm-commits]

efriedma added inline comments.


================
Comment at: lib/IR/Module.cpp:91
 
+CodeGenOpt::Level Module::getCodeGenOptLevel() const {
+  if (FunctionList.empty())
----------------
mcrosier wrote:
> efriedma wrote:
> > This doesn't make any sense.  If it's a per-function attribute, we should be computing it per function.  The maximum level set on any function doesn't have any useful meaning.
> The goal here is to approximate the codegen optimization level during LTO based on function level attributes.  Per the RFC, after r324557 the codegen optimization level for LTO is always CodeGenOpt::Default and is not configurable AFAICT.  However, the codegen optimization level has implications on how the codegen pipelines works (e.g., fast-isel vs selection dag, greedy vs. fast register allocator), which is at least one reason to try an approximate the codegen opt level (see the use of this function in lib/LTO/LTO.cpp).
> 
> On why I pick the max.. my thought is that if we're compiling with LTO the user is probably willing to aggressively optimize, so the heuristic chooses the highest optimization level...
> 
> 
> 
Whether we use fast-isel vs. selectiondag or greedy vs. fast regalloc are choices we could, and should, make at a per-function level.  Actually, we already choose between fast-isel vs. selectiondagisel on a per-function level, depending on whether optnone is specified.

I think the right design here looks very different: "optaggressive" should just be a hint that we want a different codesize/efficiency tradeoff, like "optsize".  Then we should fix optimizations to use that hint instead of the global OptLevel.  (I only count four places in lib/CodeGen/ and lib/Target/AArch64/ which actually distinguish between -O2 and -O3, so this shouldn't be difficult to implement.)


https://reviews.llvm.org/D45225