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

[Chad Rosier via llvm-dev]

Thanks, David.  I believe at least part of the discussion you're 
referring to can be found here: https://reviews.llvm.org/D28404

The issue I'm running into is that after r324557 the codegen 
optimization level during LTO defaults to CodeGenOpt::Default 
irrespective of what they user may have specified either during the 
initial compilation or during the LTO stage.

This can have an impact on how the codegen pipeline is built (e.g., for 
AArch64 the SeparateConstOffsetFromGEPPass is only added to the pipeline 
with CodeGenOpt::Aggressive) or it may impact they way a function pass 
works (e.g., MachineBlockPlacement tail duplication is only run with 
CodeGenOpt::Aggressive).

I'm particularly interested in fixing the latter case, which I think can 
be addressed by adding function attributes and then modifying the 
codegen passes to use the function attributes rather than the TargetPass 
optimization level.  However, I'm open to alternative solutions/feedback.

  Chad

On 4/4/2018 10:41 AM, David Blaikie wrote:
>
>
> On Tue, Apr 3, 2018 at 12:47 PM via llvm-dev <llvm-dev at lists.llvm.org 
> <mailto: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 <mailto: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/99de14ae/attachment.html>