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

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>

Hi Martin,

I think this is another example of why we might consider having such 
function level attributes.. yes.

  Chad


On 4/4/2018 11:42 AM, Martin J. O'Riordan via llvm-dev
wrote:
>
> 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
>
>
>
> _______________________________________________
> 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/6a2e9f87/attachment.html>

Yes, this is very useful RFC for being able to control optimization level at
function level. We may also want to provide fp-model=<fast|precised …>
control at function level via attributes as well. However, the “merge” actions
of all these attributes need to be carefully defined and designed for LTO and
IPO optimizations.

Thanks,
Xinmin

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chad
Rosier via llvm-dev
Sent: Wednesday, April 4, 2018 8:54 AM
To: Martin J. O'Riordan <MartinO at theheart.ie>; 'LLVM
Developers' <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] [RFC] Adding function attributes to represent codegen
optimization level


Hi Martin,
I think this is another example of why we might consider having such function
level attributes.. yes.

 Chad

On 4/4/2018 11:42 AM, Martin J. O'Riordan via llvm-dev wrote:
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><mailto:dblaikie at
gmail.com>; 'mcrosier at codeaurora.org<mailto:mcrosier at
codeaurora.org>' <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>
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




_______________________________________________

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/20180405/5b8f032a/attachment.html>