llvm dev - Jun 2013 - [LLVMdev] [cfe-dev] [RFC] add Function Attribute to disable optimization

Dropping opt level should not lead to ABI changes. Otherwise you won't
be able to mix-match O2 and O0 objects either.

David

On Mon, Jun 17, 2013 at 10:59 AM, jahanian <fjahanian at apple.com>
wrote:
> Wouldn’t implementing this proposal be a red herring? By this I mean, it is
> possible that
> throughout the optimization phases, there is an implied assumption that all
> functions
> are similarly optimized. An example would be under certain optimization
> flag, compiler changes
> calling convention of static functions.
>
> - Fariborz
>
> On Jun 17, 2013, at 8:58 AM, Andrea_DiBiagio at sn.scee.net wrote:
>
> Hi,
>
> I previously made a proposal for adding a pragma for per-function
> optimization level control due to a number of requests from our customers
> (See http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958 for
> the previous discussion), however the discussion was inconclusive.  Some
> of my colleagues recently had the opportunity to discuss the proposal with
> a number of people at and before the recent Bay Area social where it was
> generally agreed that we should resubmit a new scaled-down proposal that
> still addresses our users' primary use-case without introducing the
> complexity of full per-function optimization level control at this time.
>
> This proposal is to create a new function-level attribute which would tell
> the compiler to not to perform any optimizing transformations on the
> specified function.
>
> The use-case is to be able to selectively disable optimizations when
> debugging a small number of functions in a compilation unit to provide an
> -O0-like quality of debugging in cases where compiling the whole unit at
> anything less than full optimization would make the program run too
> slowly.  A useful secondary-effect of this feature would be to allow users
> to temporarily work-around optimization bugs in LLVM without having to
> reduce the optimization level for the whole compilation unit, however we
> do not consider this the most important use-case.
>
> Our suggestion for the name for this attribute is "optnone" which
seems to
> be in keeping with the existing "optsize" attribute, although it
could
> equally be called "noopt" or something else entirely.  It would
be exposed
> to Clang users through __attribute__((optnone)) or [[optnone]].
>
> I would like to discuss this proposal with the rest of the community to
> share opinions and have feedback on this.
>
> ==================================================> Interactions with
the existing function attributes:
>
> LLVM allows to decorate functions with 'noinline',
alwaysinline' and
> 'inlinehint'.  We think that it makes sense for 'optnone'
to implicitly
> imply 'noinline' (at least from a user's point of view) and
therefore
> 'optnone' should be considered incompatible with
'alwaysinline' and
> 'inlinehint'.
>
> Example:
> __attribute__((optnone, always_inline))
> void foo() { ... }
>
> In this case we could make 'optnone' override
'alwaysinline'. The effect
> would be that 'alwaysinline' wouldn't appear in the IR if
'optnone' is
> specified.
>
> Under the assumption that 'optnone' implies 'noinline',
other things that
> should be taken into account are:
> 1) functions marked as 'optnone' should never be considered as
potential
> candidates for inlining;
> 2) the inliner shouldn't try to inline a function if the call site is
in a
> 'optnone' function.
>
> Point 1 can be easily achieved by simply pushing attribute
'noinline' on
> the list of function attributes if 'optnone' is used.
> point 2 however would probably require to teach the Inliner about
> 'optnone' and how to deal with it.
>
> As in the case of 'alwaysinline' and 'inlinehint', I think
'optnone'
> should also override 'optsize'/'minsize'.
>
> Last (but not least), implementing 'optnone' would still require
changes
> in how optimizations are run on functions. This last part is probably the
> hardest part since the current optimizer does not allow the level of
> flexibility required by 'optnone'.  It seems it would either
require some
> modifications to the Pass Manager or we would have to make individual
> passes aware of the attribute.  Neither of these solutions seem
> particularly attractive to me, so I'm open to any suggestions!
>
> Thanks,
> Andrea Di Biagio
> SN Systems - Sony Computer Entertainment Group
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify postmaster at
scee.net
> This footnote also confirms that this email message has been checked for
> all known viruses.
> Sony Computer Entertainment Europe Limited
> Registered Office: 10 Great Marlborough Street, London W1F 7LP, United
> Kingdom
> Registered in England: 3277793
> **********************************************************************
>
> P Please consider the environment before printing this e-mail
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

On Jun 17, 2013, at 11:57 AM, Xinliang David Li <xinliangli at gmail.com>
wrote:
> Dropping opt level should not lead to ABI changes. Otherwise you won't
> be able to mix-match O2 and O0 objects either.
I was referring to “static functions”. Not that it happens, but something to
consider.
- Fariborz
> 
> David
> 
> On Mon, Jun 17, 2013 at 10:59 AM, jahanian <fjahanian at apple.com>
wrote:
>> Wouldn’t implementing this proposal be a red herring? By this I mean,
it is
>> possible that
>> throughout the optimization phases, there is an implied assumption that
all
>> functions
>> are similarly optimized. An example would be under certain optimization
>> flag, compiler changes
>> calling convention of static functions.
>> 
>> - Fariborz
>> 
>> On Jun 17, 2013, at 8:58 AM, Andrea_DiBiagio at sn.scee.net wrote:
>> 
>> Hi,
>> 
>> I previously made a proposal for adding a pragma for per-function
>> optimization level control due to a number of requests from our
customers
>> (See http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958
for
>> the previous discussion), however the discussion was inconclusive. 
Some
>> of my colleagues recently had the opportunity to discuss the proposal
with
>> a number of people at and before the recent Bay Area social where it
was
>> generally agreed that we should resubmit a new scaled-down proposal
that
>> still addresses our users' primary use-case without introducing the
>> complexity of full per-function optimization level control at this
time.
>> 
>> This proposal is to create a new function-level attribute which would
tell
>> the compiler to not to perform any optimizing transformations on the
>> specified function.
>> 
>> The use-case is to be able to selectively disable optimizations when
>> debugging a small number of functions in a compilation unit to provide
an
>> -O0-like quality of debugging in cases where compiling the whole unit
at
>> anything less than full optimization would make the program run too
>> slowly.  A useful secondary-effect of this feature would be to allow
users
>> to temporarily work-around optimization bugs in LLVM without having to
>> reduce the optimization level for the whole compilation unit, however
we
>> do not consider this the most important use-case.
>> 
>> Our suggestion for the name for this attribute is "optnone"
which seems to
>> be in keeping with the existing "optsize" attribute, although
it could
>> equally be called "noopt" or something else entirely.  It
would be exposed
>> to Clang users through __attribute__((optnone)) or [[optnone]].
>> 
>> I would like to discuss this proposal with the rest of the community to
>> share opinions and have feedback on this.
>> 
>> ==================================================>> Interactions
with the existing function attributes:
>> 
>> LLVM allows to decorate functions with 'noinline',
alwaysinline' and
>> 'inlinehint'.  We think that it makes sense for
'optnone' to implicitly
>> imply 'noinline' (at least from a user's point of view) and
therefore
>> 'optnone' should be considered incompatible with
'alwaysinline' and
>> 'inlinehint'.
>> 
>> Example:
>> __attribute__((optnone, always_inline))
>> void foo() { ... }
>> 
>> In this case we could make 'optnone' override
'alwaysinline'. The effect
>> would be that 'alwaysinline' wouldn't appear in the IR if
'optnone' is
>> specified.
>> 
>> Under the assumption that 'optnone' implies 'noinline',
other things that
>> should be taken into account are:
>> 1) functions marked as 'optnone' should never be considered as
potential
>> candidates for inlining;
>> 2) the inliner shouldn't try to inline a function if the call site
is in a
>> 'optnone' function.
>> 
>> Point 1 can be easily achieved by simply pushing attribute
'noinline' on
>> the list of function attributes if 'optnone' is used.
>> point 2 however would probably require to teach the Inliner about
>> 'optnone' and how to deal with it.
>> 
>> As in the case of 'alwaysinline' and 'inlinehint', I
think 'optnone'
>> should also override 'optsize'/'minsize'.
>> 
>> Last (but not least), implementing 'optnone' would still
require changes
>> in how optimizations are run on functions. This last part is probably
the
>> hardest part since the current optimizer does not allow the level of
>> flexibility required by 'optnone'.  It seems it would either
require some
>> modifications to the Pass Manager or we would have to make individual
>> passes aware of the attribute.  Neither of these solutions seem
>> particularly attractive to me, so I'm open to any suggestions!
>> 
>> Thanks,
>> Andrea Di Biagio
>> SN Systems - Sony Computer Entertainment Group
>> 
>> 
>> **********************************************************************
>> This email and any files transmitted with it are confidential and
intended
>> solely for the use of the individual or entity to whom they are
addressed.
>> If you have received this email in error please notify postmaster at
scee.net
>> This footnote also confirms that this email message has been checked
for
>> all known viruses.
>> Sony Computer Entertainment Europe Limited
>> Registered Office: 10 Great Marlborough Street, London W1F 7LP, United
>> Kingdom
>> Registered in England: 3277793
>> **********************************************************************
>> 
>> P Please consider the environment before printing this e-mail
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> 
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130617/7e7c8cbf/attachment.html>

On Mon, Jun 17, 2013 at 12:02 PM, jahanian <fjahanian at apple.com>
wrote:
>
> On Jun 17, 2013, at 11:57 AM, Xinliang David Li <xinliangli at
gmail.com>
> wrote:
>
> Dropping opt level should not lead to ABI changes. Otherwise you won't
> be able to mix-match O2 and O0 objects either.
>
>
> I was referring to “static functions”. Not that it happens, but something
to
> consider.
Not address exposed static functions.

As Chandler mentions, this would be done by an IPA pass that looks at
all the callsites -- the enclosing function's opt level should not
matter here.

David

> - Fariborz
>
>
> David
>
> On Mon, Jun 17, 2013 at 10:59 AM, jahanian <fjahanian at apple.com>
wrote:
>
> Wouldn’t implementing this proposal be a red herring? By this I mean, it is
> possible that
> throughout the optimization phases, there is an implied assumption that all
> functions
> are similarly optimized. An example would be under certain optimization
> flag, compiler changes
> calling convention of static functions.
>
> - Fariborz
>
> On Jun 17, 2013, at 8:58 AM, Andrea_DiBiagio at sn.scee.net wrote:
>
> Hi,
>
> I previously made a proposal for adding a pragma for per-function
> optimization level control due to a number of requests from our customers
> (See http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958 for
> the previous discussion), however the discussion was inconclusive.  Some
> of my colleagues recently had the opportunity to discuss the proposal with
> a number of people at and before the recent Bay Area social where it was
> generally agreed that we should resubmit a new scaled-down proposal that
> still addresses our users' primary use-case without introducing the
> complexity of full per-function optimization level control at this time.
>
> This proposal is to create a new function-level attribute which would tell
> the compiler to not to perform any optimizing transformations on the
> specified function.
>
> The use-case is to be able to selectively disable optimizations when
> debugging a small number of functions in a compilation unit to provide an
> -O0-like quality of debugging in cases where compiling the whole unit at
> anything less than full optimization would make the program run too
> slowly.  A useful secondary-effect of this feature would be to allow users
> to temporarily work-around optimization bugs in LLVM without having to
> reduce the optimization level for the whole compilation unit, however we
> do not consider this the most important use-case.
>
> Our suggestion for the name for this attribute is "optnone" which
seems to
> be in keeping with the existing "optsize" attribute, although it
could
> equally be called "noopt" or something else entirely.  It would
be exposed
> to Clang users through __attribute__((optnone)) or [[optnone]].
>
> I would like to discuss this proposal with the rest of the community to
> share opinions and have feedback on this.
>
> ==================================================> Interactions with
the existing function attributes:
>
> LLVM allows to decorate functions with 'noinline',
alwaysinline' and
> 'inlinehint'.  We think that it makes sense for 'optnone'
to implicitly
> imply 'noinline' (at least from a user's point of view) and
therefore
> 'optnone' should be considered incompatible with
'alwaysinline' and
> 'inlinehint'.
>
> Example:
> __attribute__((optnone, always_inline))
> void foo() { ... }
>
> In this case we could make 'optnone' override
'alwaysinline'. The effect
> would be that 'alwaysinline' wouldn't appear in the IR if
'optnone' is
> specified.
>
> Under the assumption that 'optnone' implies 'noinline',
other things that
> should be taken into account are:
> 1) functions marked as 'optnone' should never be considered as
potential
> candidates for inlining;
> 2) the inliner shouldn't try to inline a function if the call site is
in a
> 'optnone' function.
>
> Point 1 can be easily achieved by simply pushing attribute
'noinline' on
> the list of function attributes if 'optnone' is used.
> point 2 however would probably require to teach the Inliner about
> 'optnone' and how to deal with it.
>
> As in the case of 'alwaysinline' and 'inlinehint', I think
'optnone'
> should also override 'optsize'/'minsize'.
>
> Last (but not least), implementing 'optnone' would still require
changes
> in how optimizations are run on functions. This last part is probably the
> hardest part since the current optimizer does not allow the level of
> flexibility required by 'optnone'.  It seems it would either
require some
> modifications to the Pass Manager or we would have to make individual
> passes aware of the attribute.  Neither of these solutions seem
> particularly attractive to me, so I'm open to any suggestions!
>
> Thanks,
> Andrea Di Biagio
> SN Systems - Sony Computer Entertainment Group
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify postmaster at
scee.net
> This footnote also confirms that this email message has been checked for
> all known viruses.
> Sony Computer Entertainment Europe Limited
> Registered Office: 10 Great Marlborough Street, London W1F 7LP, United
> Kingdom
> Registered in England: 3277793
> **********************************************************************
>
> P Please consider the environment before printing this e-mail
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>