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

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

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

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>

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>

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>

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>

On 2018-04-04 22:00, Mehdi AMINI wrote:
> 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?
I'm simply stating the argument made by Peter in r324557; this is not my 
opinion.  Personally, I think it seems reasonable to allow the 
optimization flag used during the link step to control the codegen 
optimization level.  However, this is no longer the case after r324557.

FWIW, I would be very much on-board with reverting r324557 and then 
changing lld to mirror the behavior of the gold plugin, but I don't know 
if that's the consensus in the community.
> Are we encoding O1/O2/O3 optimization level into function attributes
> and trying to honor these during the LTO IR optimization pipeline as
> well?
No.  The intent of these attributes are to control the codegen pipeline 
only.  Of course this is all based on the assumption that using the 
optimization level used during bitcode generation should also be used 
with LTO in the codegen pipeline.

I don't have a strong opinion either way.  I just want codgen to respect 
the fact that I specified -O3 during both the bitcode generation and 
link steps, but that's not the case anymore.  :)

  Chad
> 
> 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