[RFC] add Function Attribute to disable optimization

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] add Function Attribute to disable optimization

Andrea_DiBiagio
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 [hidden email]
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [RFC] add Function Attribute to disable optimization

Jeffrey Walton
Hi Andrea,

This would be very useful.

On Mon, Jun 17, 2013 at 11:58 AM,  <[hidden email]> wrote:

>
> 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.
Unlike the cited use case, I encounter two others in the field during
code reviews.

First is to ensure dead-writes are not removed. For example, a
function that zeroizes or wipes memory is subject to removal during
optimization. I often have to look at program's disassembly to ensure
the memset is not removed by the optimizer.

Second is to ensure that questionable code (undefined behavior) is not
removed. I see this most often in overflow checks when the programmer
uses an `int` rather than an `usigned int`. This would also likely
relieve the need for -fwrapv since we don't have to worry about the
compiler or optimizer dropping code.

There are a few ways to get around the issues, but the easiest would
be to apply per-function optimizations through instrumentation (such
as a pragma). Microsoft compilers already allow us to do the same.

Jeff
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [RFC] add Function Attribute to disable optimization

jahanian
In reply to this post by Andrea_DiBiagio
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, [hidden email] 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 [hidden email]
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
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [RFC] add Function Attribute to disable optimization

Jeffrey Walton
On Mon, Jun 17, 2013 at 1:59 PM, jahanian <[hidden email]> 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.
Forgive my ignorance, but aren't all functions in the compilation unit
optimized at the same level? It does not matter if its a user supplied
command line or a makefile recipe.

Jeff

> On Jun 17, 2013, at 8:58 AM, [hidden email] 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.
>
> ...

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [RFC] add Function Attribute to disable optimization

jahanian

On Jun 17, 2013, at 11:12 AM, Jeffrey Walton <[hidden email]> wrote:

On Mon, Jun 17, 2013 at 1:59 PM, jahanian <[hidden email]> 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.
Forgive my ignorance, but aren't all functions in the compilation unit
optimized at the same level? It does not matter if its a user supplied
command line or a makefile recipe.

Yes. This proposal wants to change this.
- Fariborz


Jeff



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [RFC] add Function Attribute to disable optimization

Chandler Carruth-2
In reply to this post by jahanian
On Mon, Jun 17, 2013 at 10:59 AM, jahanian <[hidden email]> 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.

There is no such intrinsic assumption.

The optimizer is already perfectly capable of handling these scenarios, and they already come up. Imagine LTO of a two translation units with different optimization levels. Also see the optsize attribute.
 
An example would be under certain optimization flag, compiler changes 
calling convention of static functions.

This is always (and must always) done by a pass that looks at all of the callers together. Thus, it will be able to (and must be taught) respect any attribute on a function which is designed to turn off optimizations.

The only real challenge to this proposal is going through and teaching as much of the optimizer as possible to respect this function attribute. I don't see any really fundamentally problematic aspects to it.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [RFC] add Function Attribute to disable optimization

Xinliang David Li-2
In reply to this post by jahanian
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 <[hidden email]> 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, [hidden email] 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 [hidden email]
> 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
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [RFC] add Function Attribute to disable optimization

jahanian

On Jun 17, 2013, at 11:57 AM, Xinliang David Li <[hidden email]> 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 <[hidden email]> 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, [hidden email] 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 [hidden email]
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
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [RFC] add Function Attribute to disable optimization

Xinliang David Li-2
On Mon, Jun 17, 2013 at 12:02 PM, jahanian <[hidden email]> wrote:

>
> On Jun 17, 2013, at 11:57 AM, Xinliang David Li <[hidden email]>
> 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 <[hidden email]> 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, [hidden email] 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 [hidden email]
> 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
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] add Function Attribute to disable optimization

Nick Lewycky
In reply to this post by Andrea_DiBiagio
[hidden email] 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.

What about module passes? Do you want to disable all module passes in a
TU which contains a single one of these? I'll be unhappy if we need to
litter checks throughout the module passes that determine whether a
given instruction is inside an unoptimizable function or not. Saying
that module passes are exempt from checking the 'noopt' attribute is
fine to me, but then somebody needs to know how to module passes (and
users may be surprised to discover that adding such an annotation to one
function will cause seemingly-unrelated functions to become less optimized).

Nick

> 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 [hidden email]
> 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
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [RFC] add Function Attribute to disable optimization

Sean Silva
In reply to this post by Jeffrey Walton



On Mon, Jun 17, 2013 at 10:29 AM, Jeffrey Walton <[hidden email]> wrote:

First is to ensure dead-writes are not removed. For example, a
function that zeroizes or wipes memory is subject to removal during
optimization. I often have to look at program's disassembly to ensure
the memset is not removed by the optimizer.

Appropriate use of `volatile` is probably sufficient for this use case.
 
-- Sean Silva

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [RFC] add Function Attribute to disable optimization

Jeffrey Walton
On Mon, Jun 17, 2013 at 6:23 PM, Sean Silva <[hidden email]> wrote:
> On Mon, Jun 17, 2013 at 10:29 AM, Jeffrey Walton <[hidden email]> wrote:
>> First is to ensure dead-writes are not removed. For example, a
>> function that zeroizes or wipes memory is subject to removal during
>> optimization. I often have to look at program's disassembly to ensure
>> the memset is not removed by the optimizer.
>
> Appropriate use of `volatile` is probably sufficient for this use case.
That brings up a good point. As I understand it, volatile is
essentially implementation defined. What is Clang/LLVM's
interpretation?

Here's what I know. Microsoft's interpretation allows me to use
volatile for the situation under MSVC++ [1]. GCC's interpretation of
volatile is for memory mapped hardware, so it does not allow me to use
the qualifier to tame the optimizer [2].

Jeff

[1] http://msdn.microsoft.com/en-us/library/vstudio/12a04hfd%28v=vs.90%29.aspx
[2] http://gcc.gnu.org/ml/gcc-help/2012-03/msg00242.html
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [RFC] add Function Attribute to disable optimization

Eli Friedman-2
On Mon, Jun 17, 2013 at 3:32 PM, Jeffrey Walton <[hidden email]> wrote:
On Mon, Jun 17, 2013 at 6:23 PM, Sean Silva <[hidden email]> wrote:
> On Mon, Jun 17, 2013 at 10:29 AM, Jeffrey Walton <[hidden email]> wrote:
>> First is to ensure dead-writes are not removed. For example, a
>> function that zeroizes or wipes memory is subject to removal during
>> optimization. I often have to look at program's disassembly to ensure
>> the memset is not removed by the optimizer.
>
> Appropriate use of `volatile` is probably sufficient for this use case.
That brings up a good point. As I understand it, volatile is
essentially implementation defined. What is Clang/LLVM's
interpretation?

Here's what I know. Microsoft's interpretation allows me to use
volatile for the situation under MSVC++ [1]. GCC's interpretation of
volatile is for memory mapped hardware, so it does not allow me to use
the qualifier to tame the optimizer [2].


clang doesn't treat volatile loads/stores as aquire/release barriers, if that's what you're asking.

Actually, if you look at the 2012 version of the docs "http://msdn.microsoft.com/en-us/library/vstudio/12a04hfd(v=vs.110).aspx", you can see Microsoft was forced to change its own rules so as to not completely screw over performance on non-X86 platforms.

-Eli

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [RFC] add Function Attribute to disable optimization

Sean Silva
In reply to this post by Jeffrey Walton
On Mon, Jun 17, 2013 at 3:32 PM, Jeffrey Walton <[hidden email]> wrote:
On Mon, Jun 17, 2013 at 6:23 PM, Sean Silva <[hidden email]> wrote:
> On Mon, Jun 17, 2013 at 10:29 AM, Jeffrey Walton <[hidden email]> wrote:
>> First is to ensure dead-writes are not removed. For example, a
>> function that zeroizes or wipes memory is subject to removal during
>> optimization. I often have to look at program's disassembly to ensure
>> the memset is not removed by the optimizer.
>
> Appropriate use of `volatile` is probably sufficient for this use case.
That brings up a good point. As I understand it, volatile is
essentially implementation defined. What is Clang/LLVM's
interpretation?

Here's what I know. Microsoft's interpretation allows me to use
volatile for the situation under MSVC++ [1]. GCC's interpretation of
volatile is for memory mapped hardware, so it does not allow me to use
the qualifier to tame the optimizer [2].

Jeff

[1] http://msdn.microsoft.com/en-us/library/vstudio/12a04hfd%28v=vs.90%29.aspx
[2] http://gcc.gnu.org/ml/gcc-help/2012-03/msg00242.html

`volatile` roughly means "this memory access may have side effects beyond those of regular memory". Since the compiler can't reason about these memory accesses, it is forced to carry them down to the assembly "as written" without tampering with them. AFAIK `volatile` is sufficient for making loads and stores unelidable (which was your original use case).


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] add Function Attribute to disable optimization

Andrea_DiBiagio
In reply to this post by Nick Lewycky
Hi Nick,

> From: Nick Lewycky <[hidden email]>
> > 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.
>
> What about module passes? Do you want to disable all module passes in a
> TU which contains a single one of these? I'll be unhappy if we need to
> litter checks throughout the module passes that determine whether a
> given instruction is inside an unoptimizable function or not. Saying
> that module passes are exempt from checking the 'noopt' attribute is
> fine to me, but then somebody needs to know how to module passes (and
> users may be surprised to discover that adding such an annotation to one

> function will cause seemingly-unrelated functions to become less
optimized).

Right, module passes are a difficult case.
I understand your point. I think ignoring the `noopt' attribute (or
whatever we want to call it) may be the best approach in this case: it
avoid the problems you describe but should still be sufficient for the
purposes we care about. I am currently studying the module passes in more
details to be certain about this.

Thanks for the useful feedback,
Andrea Di Biagio
SN Systems - Sony Computer Entertainment Group

> > 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
[hidden email]
> > 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
> > _______________________________________________
> > LLVM Developers mailing list
> > [hidden email]         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>


**********************************************************************
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 [hidden email]
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] add Function Attribute to disable optimization

Andrea_DiBiagio
In reply to this post by Nick Lewycky
So..
I have investigated more on how a new function attribute to disable
optimization on a per-function basis could be implemented.
At the current state, with the lack of specific support from the pass
managers I found two big problems when trying to implement a prototype
implementation of the new attribute.

Here are the problems found:
1) It is not safe to disable some transform passes in the backend.
It looks like there are some unwritten dependences between passes and
disrupting the sequence of passes to run may result in unexpected crashes
and/or assertion failures;
2)  The fact that pass managers are not currently designed to support
per-function optimization makes it difficult to find a reasonable way to
implement this new feature.

About point 2. the Idea that came in my mind consisted in making passes
aware of the 'noopt' attribute.
In my experiment:
 - I added a virtual method called 'mustAlwaysRun' in class Pass that
'returns true if it is not safe to disable this pass'.
If a pass does not override the default implementation of that method,
then by default it will always return true (i.e. the pass "must
always run" pass even when attribute 'noopt' is specified).
 - I then redefined in override that method on all the optimization passes
that could have been safely turned off when attribute noopt was present.
In my experiment, I specifically didn't disable Module Passes;
 - Then I modified the 'doInitialize()' 'run*()' and 'doFinalize' methods
in Pass Manger to check for both the presence of attribute noopt AND the
value returned by method 'mustAlwaysRun' called on the current pass
instance.

That experiment seemed to "work" on a few tests and benchmarks.
However:
 a) 'noopt' wouldn't really imply no optimization, since not all codegen
optimization passes can be safely disabled. As a result, the assembly
produced for noopt functions had few differences with respect to the
assembly generated for the same functions at -O0;
 b) I don't particularly like the idea of making passes "aware" of the
'noopt' attribute. However, I don't know if there is a reasonable way to
implement the noopt attribute without having to re-design how pass
managers work.
  c)  Because of a. and b.,  I am concerned that a change like the one
described above won't be accepted. If so however, I would be really
interested in the feedback from the community. Maybe there are better ways
to implement 'noopt' which I don't know/didn't think about?

As I said, I am not very happy with the proposed solution and any feedback
would be really appreciated at this point.

By the way, here is how I thought the 'noopt' proposal could have been
contributed in terms of patches:

[LLVM IR][Patch 1]
================
This patch extends the IR adding a new attribute called 'noopt'.
Below, is a sequence of steps which describes how to implement this patch.

1) Add a definition for attribute 'noopt' in File llvm/IR/Attribute.h;
2) Teach how attribute 'noopt' should be encoded and also how to print it
out
   as a string value (File lib/IR/Attributes.cpp);
2b) Add a new enum value for the new attribute in enum LLVMAttribute
    (File "include/llvm-c/Core.h");
3) The new attribute is a function attribute;
   Teach the verifier pass that 'noopt' is a function attribute;
   Add checks in method VerifyAttributeTypes() (File lib/IR/Verifier.cpp):
   * NoOpt is a function-only attribute;
   * Assert if NoOpt is used in the same context as alwaysinline;
   * Assert if NoOpt is used in the same context as OptimizeForSize
(needed?);
   * Assert if NoOpt is used in the same context as MinSize (needed?).
4) Add a LLVM test in test/Feature to verify that we correctly disassemble
   the new function attribute (see for example file cold.ll);
5) Teach the AsmParser how to parse the new attribute:
 * Add a new token for the new attribute noopt;
 * Add rules to parse the new token;
6) Add a description of the new attribute in "docs/LangRef.rst";

[LLVM][Opt][Patch 2]
==================
This patch implements the required changes to passes and pass managers.
Below, is a sequence of steps which describes how to implement this patch.

1) Make the new inliner aware of the new flag.
 * In lib/Transforms/IPO/Inliner.cpp:
   ** do not inline the callee if it is not always_inline and the caller
is marked 'noopt'.
 * No other changes are required since 'noopt' already implies 'noinline'.
2) Tell the pass manager which transform passes can be safely disabled
with 'noopt'.

[CLANG][Patch 3]
===============
This patch teaches clang how to parse and generate code for functions that
are marked with attribute 'noopt'.

1) Lex
 * Add a new token for the 'noopt' keyword.
 * That keyword is for a function attribute.
2) Sema
 * Add a rule to handle the case where noopt is passed as function
attribute.
 * check that the attribute does not take extra arguments.
 * check that the attribute is associated to a function declaration.
 * Add the attribute to the IR Set of Attributes.
3) CodeGen
 * noopt implies 'noinline.
 * noopt always wins over always_inline
 * noopt does not win over 'naked': naked functions only contain asm
   statements. This attribute is only valid for ARM, AVX, MCORE, RL78, RX
and
   SPU to indicate that the specified function does not need
prologue/epilogue
   sequence generated by the compiler. (NOTE: this constraint can be
removed).
4) Add clang tests:
 * in test/Sema:
   ** Verify that noopt only applies to functions. (-cc1 -fsyntax-only
-verify)
 * in test/CodeGen:
   ** Check that noopt implies noinline
   ** Check combinations of noopt and noinline and always_inline


Andrea Di Biagio
SN Systems - Sony Computer Entertainment Group.

Andrea DiBiagio/SN R&D/BS/UK/SCEE wrote on 25/06/2013 15:20:12:

> From: Andrea DiBiagio/SN R&D/BS/UK/SCEE
> To: Nick Lewycky <[hidden email]>
> Cc: [hidden email], [hidden email]
> Date: 25/06/2013 15:20
> Subject: Re: [LLVMdev] [RFC] add Function Attribute to disable
optimization
>
> Hi Nick,
>
> > From: Nick Lewycky <[hidden email]>
> > > 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.
> >
> > What about module passes? Do you want to disable all module passes in
a
> > TU which contains a single one of these? I'll be unhappy if we need to

> > litter checks throughout the module passes that determine whether a
> > given instruction is inside an unoptimizable function or not. Saying
> > that module passes are exempt from checking the 'noopt' attribute is
> > fine to me, but then somebody needs to know how to module passes (and
> > users may be surprised to discover that adding such an annotation to
one
> > function will cause seemingly-unrelated functions to become less
optimized).

> Right, module passes are a difficult case.
> I understand your point. I think ignoring the `noopt' attribute (or
> whatever we want to call it) may be the best approach in this case:
> it avoid the problems you describe but should still be sufficient
> for the purposes we care about. I am currently studying the module
> passes in more details to be certain about this.

> Thanks for the useful feedback,
> Andrea Di Biagio
> SN Systems - Sony Computer Entertainment Group
>
> > > 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
[hidden email]
> > > 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
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > [hidden email]         http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > >
> >
>
>
> **********************************************************************
> 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 [hidden email]
> 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

**********************************************************************
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 [hidden email]
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] add Function Attribute to disable optimization

Nick Lewycky
[hidden email] wrote:
> So..
> I have investigated more on how a new function attribute to disable
> optimization on a per-function basis could be implemented.
> At the current state, with the lack of specific support from the pass
> managers I found two big problems when trying to implement a prototype
> implementation of the new attribute.
>
> Here are the problems found:
> 1) It is not safe to disable some transform passes in the backend.

Hold on. By 'backend' do you mean LLVM IR FunctionPasses, or LLVM
CodeGen MachineFunctionPasses? The former you should be able to turn
off, reorder, etc., at will. The latter is a fixed pipeline, you either
choose the -O0 pipeline or the -O2 pipeline.

If you find that turning off IR-level passes is triggering assertions,
please start filing bugs.

Nick

> It looks like there are some unwritten dependences between passes and
> disrupting the sequence of passes to run may result in unexpected crashes
> and/or assertion failures;
> 2)  The fact that pass managers are not currently designed to support
> per-function optimization makes it difficult to find a reasonable way to
> implement this new feature.
>
> About point 2. the Idea that came in my mind consisted in making passes
> aware of the 'noopt' attribute.
> In my experiment:
>   - I added a virtual method called 'mustAlwaysRun' in class Pass that
> 'returns true if it is not safe to disable this pass'.
> If a pass does not override the default implementation of that method,
> then by default it will always return true (i.e. the pass "must
> always run" pass even when attribute 'noopt' is specified).
>   - I then redefined in override that method on all the optimization passes
> that could have been safely turned off when attribute noopt was present.
> In my experiment, I specifically didn't disable Module Passes;
>   - Then I modified the 'doInitialize()' 'run*()' and 'doFinalize' methods
> in Pass Manger to check for both the presence of attribute noopt AND the
> value returned by method 'mustAlwaysRun' called on the current pass
> instance.
>
> That experiment seemed to "work" on a few tests and benchmarks.
> However:
>   a) 'noopt' wouldn't really imply no optimization, since not all codegen
> optimization passes can be safely disabled. As a result, the assembly
> produced for noopt functions had few differences with respect to the
> assembly generated for the same functions at -O0;
>   b) I don't particularly like the idea of making passes "aware" of the
> 'noopt' attribute. However, I don't know if there is a reasonable way to
> implement the noopt attribute without having to re-design how pass
> managers work.
>    c)  Because of a. and b.,  I am concerned that a change like the one
> described above won't be accepted. If so however, I would be really
> interested in the feedback from the community. Maybe there are better ways
> to implement 'noopt' which I don't know/didn't think about?
>
> As I said, I am not very happy with the proposed solution and any feedback
> would be really appreciated at this point.
>
> By the way, here is how I thought the 'noopt' proposal could have been
> contributed in terms of patches:
>
> [LLVM IR][Patch 1]
> ================
> This patch extends the IR adding a new attribute called 'noopt'.
> Below, is a sequence of steps which describes how to implement this patch.
>
> 1) Add a definition for attribute 'noopt' in File llvm/IR/Attribute.h;
> 2) Teach how attribute 'noopt' should be encoded and also how to print it
> out
>     as a string value (File lib/IR/Attributes.cpp);
> 2b) Add a new enum value for the new attribute in enum LLVMAttribute
>      (File "include/llvm-c/Core.h");
> 3) The new attribute is a function attribute;
>     Teach the verifier pass that 'noopt' is a function attribute;
>     Add checks in method VerifyAttributeTypes() (File lib/IR/Verifier.cpp):
>     * NoOpt is a function-only attribute;
>     * Assert if NoOpt is used in the same context as alwaysinline;
>     * Assert if NoOpt is used in the same context as OptimizeForSize
> (needed?);
>     * Assert if NoOpt is used in the same context as MinSize (needed?).
> 4) Add a LLVM test in test/Feature to verify that we correctly disassemble
>     the new function attribute (see for example file cold.ll);
> 5) Teach the AsmParser how to parse the new attribute:
>   * Add a new token for the new attribute noopt;
>   * Add rules to parse the new token;
> 6) Add a description of the new attribute in "docs/LangRef.rst";
>
> [LLVM][Opt][Patch 2]
> ==================
> This patch implements the required changes to passes and pass managers.
> Below, is a sequence of steps which describes how to implement this patch.
>
> 1) Make the new inliner aware of the new flag.
>   * In lib/Transforms/IPO/Inliner.cpp:
>     ** do not inline the callee if it is not always_inline and the caller
> is marked 'noopt'.
>   * No other changes are required since 'noopt' already implies 'noinline'.
> 2) Tell the pass manager which transform passes can be safely disabled
> with 'noopt'.
>
> [CLANG][Patch 3]
> ===============
> This patch teaches clang how to parse and generate code for functions that
> are marked with attribute 'noopt'.
>
> 1) Lex
>   * Add a new token for the 'noopt' keyword.
>   * That keyword is for a function attribute.
> 2) Sema
>   * Add a rule to handle the case where noopt is passed as function
> attribute.
>   * check that the attribute does not take extra arguments.
>   * check that the attribute is associated to a function declaration.
>   * Add the attribute to the IR Set of Attributes.
> 3) CodeGen
>   * noopt implies 'noinline.
>   * noopt always wins over always_inline
>   * noopt does not win over 'naked': naked functions only contain asm
>     statements. This attribute is only valid for ARM, AVX, MCORE, RL78, RX
> and
>     SPU to indicate that the specified function does not need
> prologue/epilogue
>     sequence generated by the compiler. (NOTE: this constraint can be
> removed).
> 4) Add clang tests:
>   * in test/Sema:
>     ** Verify that noopt only applies to functions. (-cc1 -fsyntax-only
> -verify)
>   * in test/CodeGen:
>     ** Check that noopt implies noinline
>     ** Check combinations of noopt and noinline and always_inline
>
>
> Andrea Di Biagio
> SN Systems - Sony Computer Entertainment Group.
>
> Andrea DiBiagio/SN R&D/BS/UK/SCEE wrote on 25/06/2013 15:20:12:
>
>> From: Andrea DiBiagio/SN R&D/BS/UK/SCEE
>> To: Nick Lewycky<[hidden email]>
>> Cc: [hidden email], [hidden email]
>> Date: 25/06/2013 15:20
>> Subject: Re: [LLVMdev] [RFC] add Function Attribute to disable
> optimization
>>
>> Hi Nick,
>>
>>> From: Nick Lewycky<[hidden email]>
>>>> 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.
>>>
>>> What about module passes? Do you want to disable all module passes in
> a
>>> TU which contains a single one of these? I'll be unhappy if we need to
>
>>> litter checks throughout the module passes that determine whether a
>>> given instruction is inside an unoptimizable function or not. Saying
>>> that module passes are exempt from checking the 'noopt' attribute is
>>> fine to me, but then somebody needs to know how to module passes (and
>>> users may be surprised to discover that adding such an annotation to
> one
>>> function will cause seemingly-unrelated functions to become less
> optimized).
>
>> Right, module passes are a difficult case.
>> I understand your point. I think ignoring the `noopt' attribute (or
>> whatever we want to call it) may be the best approach in this case:
>> it avoid the problems you describe but should still be sufficient
>> for the purposes we care about. I am currently studying the module
>> passes in more details to be certain about this.
>
>> Thanks for the useful feedback,
>> Andrea Di Biagio
>> SN Systems - Sony Computer Entertainment Group
>>
>>>> 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
> [hidden email]
>>>> 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
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> [hidden email]         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>>
>>
>>
>> **********************************************************************
>> 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 [hidden email]
>> 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
>
> **********************************************************************
> 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 [hidden email]
> 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
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] add Function Attribute to disable optimization

Andrea_DiBiagio
> From: Nick Lewycky <[hidden email]>
> [hidden email] wrote:
> > So..
> > I have investigated more on how a new function attribute to disable
> > optimization on a per-function basis could be implemented.
> > At the current state, with the lack of specific support from the pass
> > managers I found two big problems when trying to implement a prototype
> > implementation of the new attribute.
> >
> > Here are the problems found:
> > 1) It is not safe to disable some transform passes in the backend.
>
> Hold on. By 'backend' do you mean LLVM IR FunctionPasses, or LLVM
> CodeGen MachineFunctionPasses? The former you should be able to turn
> off, reorder, etc., at will. The latter is a fixed pipeline, you either
> choose the -O0 pipeline or the -O2 pipeline.

Sorry, I meant CodeGen MachineFunctionPasses.


**********************************************************************
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 [hidden email]
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [RFC] add Function Attribute to disable optimization

Sean Silva
In reply to this post by Andrea_DiBiagio



On Thu, Jul 18, 2013 at 8:23 AM, <[hidden email]> wrote:
So..
I have investigated more on how a new function attribute to disable
optimization on a per-function basis could be implemented.
At the current state, with the lack of specific support from the pass
managers I found two big problems when trying to implement a prototype
implementation of the new attribute.

Here are the problems found:
1) It is not safe to disable some transform passes in the backend.
It looks like there are some unwritten dependences between passes and
disrupting the sequence of passes to run may result in unexpected crashes
and/or assertion failures;

This sounds like a bug. It's probably worth bringing up as its own discussion on llvmdev if it is extremely prevalent, or file PR's (or send patches fixing it!) if it is just a few isolated cases.
 
2)  The fact that pass managers are not currently designed to support
per-function optimization makes it difficult to find a reasonable way to
implement this new feature.

About point 2. the Idea that came in my mind consisted in making passes
aware of the 'noopt' attribute.
In my experiment:
 - I added a virtual method called 'mustAlwaysRun' in class Pass that
'returns true if it is not safe to disable this pass'.
If a pass does not override the default implementation of that method,
then by default it will always return true (i.e. the pass "must
always run" pass even when attribute 'noopt' is specified).
 - I then redefined in override that method on all the optimization passes
that could have been safely turned off when attribute noopt was present.
In my experiment, I specifically didn't disable Module Passes;
 - Then I modified the 'doInitialize()' 'run*()' and 'doFinalize' methods
in Pass Manger to check for both the presence of attribute noopt AND the
value returned by method 'mustAlwaysRun' called on the current pass
instance.

That experiment seemed to "work" on a few tests and benchmarks.
However:
 a) 'noopt' wouldn't really imply no optimization, since not all codegen
optimization passes can be safely disabled. As a result, the assembly
produced for noopt functions had few differences with respect to the
assembly generated for the same functions at -O0;
 b) I don't particularly like the idea of making passes "aware" of the
'noopt' attribute. However, I don't know if there is a reasonable way to
implement the noopt attribute without having to re-design how pass
managers work.

A redesign of the pass manager has been on the table for a while and the need seems more pressing daily. Definitely make sure that this use case is brought up in any design discussions for the new pass manager.

-- Sean Silva
 
  c)  Because of a. and b.,  I am concerned that a change like the one
described above won't be accepted. If so however, I would be really
interested in the feedback from the community. Maybe there are better ways
to implement 'noopt' which I don't know/didn't think about?

As I said, I am not very happy with the proposed solution and any feedback
would be really appreciated at this point.

By the way, here is how I thought the 'noopt' proposal could have been
contributed in terms of patches:

[LLVM IR][Patch 1]
================
This patch extends the IR adding a new attribute called 'noopt'.
Below, is a sequence of steps which describes how to implement this patch.

1) Add a definition for attribute 'noopt' in File llvm/IR/Attribute.h;
2) Teach how attribute 'noopt' should be encoded and also how to print it
out
   as a string value (File lib/IR/Attributes.cpp);
2b) Add a new enum value for the new attribute in enum LLVMAttribute
    (File "include/llvm-c/Core.h");
3) The new attribute is a function attribute;
   Teach the verifier pass that 'noopt' is a function attribute;
   Add checks in method VerifyAttributeTypes() (File lib/IR/Verifier.cpp):
   * NoOpt is a function-only attribute;
   * Assert if NoOpt is used in the same context as alwaysinline;
   * Assert if NoOpt is used in the same context as OptimizeForSize
(needed?);
   * Assert if NoOpt is used in the same context as MinSize (needed?).
4) Add a LLVM test in test/Feature to verify that we correctly disassemble
   the new function attribute (see for example file cold.ll);
5) Teach the AsmParser how to parse the new attribute:
 * Add a new token for the new attribute noopt;
 * Add rules to parse the new token;
6) Add a description of the new attribute in "docs/LangRef.rst";

[LLVM][Opt][Patch 2]
==================
This patch implements the required changes to passes and pass managers.
Below, is a sequence of steps which describes how to implement this patch.

1) Make the new inliner aware of the new flag.
 * In lib/Transforms/IPO/Inliner.cpp:
   ** do not inline the callee if it is not always_inline and the caller
is marked 'noopt'.
 * No other changes are required since 'noopt' already implies 'noinline'.
2) Tell the pass manager which transform passes can be safely disabled
with 'noopt'.

[CLANG][Patch 3]
===============
This patch teaches clang how to parse and generate code for functions that
are marked with attribute 'noopt'.

1) Lex
 * Add a new token for the 'noopt' keyword.
 * That keyword is for a function attribute.
2) Sema
 * Add a rule to handle the case where noopt is passed as function
attribute.
 * check that the attribute does not take extra arguments.
 * check that the attribute is associated to a function declaration.
 * Add the attribute to the IR Set of Attributes.
3) CodeGen
 * noopt implies 'noinline.
 * noopt always wins over always_inline
 * noopt does not win over 'naked': naked functions only contain asm
   statements. This attribute is only valid for ARM, AVX, MCORE, RL78, RX
and
   SPU to indicate that the specified function does not need
prologue/epilogue
   sequence generated by the compiler. (NOTE: this constraint can be
removed).
4) Add clang tests:
 * in test/Sema:
   ** Verify that noopt only applies to functions. (-cc1 -fsyntax-only
-verify)
 * in test/CodeGen:
   ** Check that noopt implies noinline
   ** Check combinations of noopt and noinline and always_inline


Andrea Di Biagio
SN Systems - Sony Computer Entertainment Group.

Andrea DiBiagio/SN R&D/BS/UK/SCEE wrote on 25/06/2013 15:20:12:

> From: Andrea DiBiagio/SN R&D/BS/UK/SCEE
> To: Nick Lewycky <[hidden email]>
> Cc: [hidden email], [hidden email]
> Date: 25/06/2013 15:20
> Subject: Re: [LLVMdev] [RFC] add Function Attribute to disable
optimization
>
> Hi Nick,
>
> > From: Nick Lewycky <[hidden email]>
> > > 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.
> >
> > What about module passes? Do you want to disable all module passes in
a
> > TU which contains a single one of these? I'll be unhappy if we need to

> > litter checks throughout the module passes that determine whether a
> > given instruction is inside an unoptimizable function or not. Saying
> > that module passes are exempt from checking the 'noopt' attribute is
> > fine to me, but then somebody needs to know how to module passes (and
> > users may be surprised to discover that adding such an annotation to
one
> > function will cause seemingly-unrelated functions to become less
optimized).

> Right, module passes are a difficult case.
> I understand your point. I think ignoring the `noopt' attribute (or
> whatever we want to call it) may be the best approach in this case:
> it avoid the problems you describe but should still be sufficient
> for the purposes we care about. I am currently studying the module
> passes in more details to be certain about this.

> Thanks for the useful feedback,
> Andrea Di Biagio
> SN Systems - Sony Computer Entertainment Group
>
> > > 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
[hidden email]
> > > 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
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > [hidden email]         http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > >
> >
>
>
> **********************************************************************
> 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 [hidden email]
> 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

**********************************************************************
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 [hidden email]
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
_______________________________________________


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] [RFC] add Function Attribute to disable optimization

Andrea_DiBiagio
> From: Sean Silva <[hidden email]>
> Here are the problems found:
> 1) It is not safe to disable some transform passes in the backend.
> It looks like there are some unwritten dependences between passes and
> disrupting the sequence of passes to run may result in unexpected
crashes
> and/or assertion failures;
>
> This sounds like a bug. It's probably worth bringing up as its own
> discussion on llvmdev if it is extremely prevalent, or file PR's (or
> send patches fixing it!) if it is just a few isolated cases.

It looks like the problem was in my code and it was caused by the lack of
update on the set of preserved analysis; as soon as the problem was fixed,
all the unexpected failures disappeared.

> 2)  The fact that pass managers are not currently designed to support
> per-function optimization makes it difficult to find a reasonable way to
> implement this new feature.
>
> About point 2. the Idea that came in my mind consisted in making passes
> aware of the 'noopt' attribute.
> In my experiment:
>  - I added a virtual method called 'mustAlwaysRun' in class Pass that
> 'returns true if it is not safe to disable this pass'.
> If a pass does not override the default implementation of that method,
> then by default it will always return true (i.e. the pass "must
> always run" pass even when attribute 'noopt' is specified).
>  - I then redefined in override that method on all the optimization
passes
> that could have been safely turned off when attribute noopt was present.
> In my experiment, I specifically didn't disable Module Passes;
>  - Then I modified the 'doInitialize()' 'run*()' and 'doFinalize'
methods

> in Pass Manger to check for both the presence of attribute noopt AND the
> value returned by method 'mustAlwaysRun' called on the current pass
> instance.
>
> That experiment seemed to "work" on a few tests and benchmarks.
> However:
>  a) 'noopt' wouldn't really imply no optimization, since not all codegen
> optimization passes can be safely disabled. As a result, the assembly
> produced for noopt functions had few differences with respect to the
> assembly generated for the same functions at -O0;
>  b) I don't particularly like the idea of making passes "aware" of the
> 'noopt' attribute. However, I don't know if there is a reasonable way to
> implement the noopt attribute without having to re-design how pass
> managers work.
>
> A redesign of the pass manager has been on the table for a while and
> the need seems more pressing daily. Definitely make sure that this
> use case is brought up in any design discussions for the new pass
manager.
>
> -- Sean Silva

Sure, I will definitely bring up this as soon as there will be a
discussion about the pass manager.

As I mentioned in my previous post, there could be a way to implement the
'noopt' attribute without having to redesign the pass manager.
However it would require that we explicitly mark function passes that are
expected to not run on a function marked as 'noopt'. That would guide the
pass manager when selecting which passes to initialize/run/finalize on a
'noopt' function.

What I don't like about that approach is the fact that passes would know
about the noopt flag. Not only it would require changes in most of the
already existent passes, but also it would force people who develop
optimization passes to know about the existence of 'noopt' when they
define their pass..

My questions are:
would it be reasonable/acceptable at this point to implement this proposal
before the pass manager is redesigned?
If so, a solution like the one described above would be acceptable? Or are
there better solutions?

Any feedback (either good or bad) would be really appreciated at this
point.

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 [hidden email]
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev