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

[David Blaikie via llvm-dev]

On Tue, Apr 3, 2018 at 12:47 PM via llvm-dev <llvm-dev at lists.llvm.org>
wrote:

> 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).
>

At least as I recall the discussion around optnone/optsize in the pass was
that these were in some way special semantically distinct properties
(optnone being "good for debugging" (or good for debugging compilers -
what's the baseline behavior before optimizations are applied), optsize
being "make this fit into something it wouldn't otherwise fit into") but
that the gradiations of -ON didn't fit into this kind of model & wouldn't
ever be implemented as function attributes.

CC'd Chandler & Eric who I think had opinions/were involved in those
previous discussions.


>
> 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/20180404/0f0b0ba3/attachment.html>