[llvm-dev] [RFC] Adding function attributes to represent codegen optimization level

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Wed Apr 4 19:00:44 PDT 2018


Le mar. 3 avr. 2018 à 12:47, via llvm-dev <llvm-dev at lists.llvm.org> a
écrit :

> All,
> A recent commit, D43040/r324557, changed the behavior of the gold plugin
> when compiling with LTO.  The change now causes the codegen optimization
> level to default to CodeGenOpt::Default (i.e., -O2) rather than use the
> LTO optimization level.  The argument was made that the LTO optimization
> level should control the amount of cross-module optimizations done by
> LTO, but it should not control the codegen optimization level; that
> should be based off of the optimization level used during the initial
> compilation phase (i.e., bitcode generation).
>

I actually don't understand this clearly.

Unless we're saying that we would change the IR optimization level either
using the -OX flag during LTO (which is clumsy, because what is a
"cross-module optimization" alone?), why would the `-OX` flag change the
Codegen optimization level when passed to clang without LTO, but it
wouldn't during LTO?
Are we encoding O1/O2/O3 optimization level into function attributes and
trying to honor these during the LTO IR optimization pipeline as well?

Thanks,

-- 
Mehdi





>
> Assuming the argument is reasonable (it make sense to me), I was hoping
> to solicit feedback on how to proceed.  The suggestion in D43040/r324557
> was to add function attributes to represent the compile-time
> optimization level (which also seems reasonable to me).
>
> As a first step, I've put together two patches: 1) an llvm patch that
> adds the function attributes to the LLVM IR and 2) a clang patch that
> attaches these attributes to each function based on the codegen
> optimization level.  I then use the function level attributes to
> "reconstruct" to codegen optimization level used with LTO.
>
> Please understand this is very much a WIP and just a very small step
> towards a final solution.
>
> Here are the patches for reference:
> Clang: D45226
> LLVM: D45225
>
> Regards,
>   Chad
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180405/b9413d7c/attachment.html>


More information about the llvm-dev mailing list