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

Wed Apr 4 08:42:08 PDT 2018

Sorry, my reply “to all” left out LLVM-Dev

From: Martin J. O'Riordan [mailto:MartinO at theheart.ie] 
Sent: 04 April 2018 16:41
To: 'David Blaikie' <dblaikie at gmail.com>; 'mcrosier at codeaurora.org' <mcrosier at codeaurora.org>; 'Chandler Carruth' <chandlerc at gmail.com>; 'Eric Christopher' <echristo at gmail.com>
Subject: RE: [llvm-dev] [RFC] Adding function attributes to represent codegen optimization level

Would implementing GCC’s ‘__attribute__((optimize(...)))’ help?

I can’t find any good documentation for this attribute, but it seems that GCC supports this in two forms:

__attribute__((optimize(2)))

meaning optimise equivalent to ‘-O2’, and:

__attribute_((optimize("fblah", "O1")))

meaning optimise with the provided discrete options.

            MartinO

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David Blaikie via llvm-dev
Sent: 04 April 2018 15:41
To: mcrosier at codeaurora.org <mailto:mcrosier at codeaurora.org> ; Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com> >; Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com> >
Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> 
Subject: Re: [llvm-dev] [RFC] Adding function attributes to represent codegen optimization level

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/4bcc3a2d/attachment.html>