[LLVMdev] [RFC] add Function Attribute to disable optimization

[Andrea_DiBiagio at sn.scee.net]

Hi,

I previously made a proposal for adding a pragma for per-function 
optimization level control due to a number of requests from our customers 
(See http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958 for 
the previous discussion), however the discussion was inconclusive.  Some 
of my colleagues recently had the opportunity to discuss the proposal with 
a number of people at and before the recent Bay Area social where it was 
generally agreed that we should resubmit a new scaled-down proposal that 
still addresses our users' primary use-case without introducing the 
complexity of full per-function optimization level control at this time.

This proposal is to create a new function-level attribute which would tell 
the compiler to not to perform any optimizing transformations on the 
specified function.

The use-case is to be able to selectively disable optimizations when 
debugging a small number of functions in a compilation unit to provide an 
-O0-like quality of debugging in cases where compiling the whole unit at 
anything less than full optimization would make the program run too 
slowly.  A useful secondary-effect of this feature would be to allow users 
to temporarily work-around optimization bugs in LLVM without having to 
reduce the optimization level for the whole compilation unit, however we 
do not consider this the most important use-case.

Our suggestion for the name for this attribute is "optnone" which seems to 
be in keeping with the existing "optsize" attribute, although it could 
equally be called "noopt" or something else entirely.  It would be exposed 
to Clang users through __attribute__((optnone)) or [[optnone]].

I would like to discuss this proposal with the rest of the community to 
share opinions and have feedback on this.

===================================================
Interactions with the existing function attributes:

LLVM allows to decorate functions with 'noinline', alwaysinline' and 
'inlinehint'.  We think that it makes sense for 'optnone' to implicitly 
imply 'noinline' (at least from a user's point of view) and therefore 
'optnone' should be considered incompatible with 'alwaysinline' and 
'inlinehint'.

Example:
__attribute__((optnone, always_inline))
void foo() { ... }

In this case we could make 'optnone' override 'alwaysinline'. The effect 
would be that 'alwaysinline' wouldn't appear in the IR if 'optnone' is 
specified.

Under the assumption that 'optnone' implies 'noinline', other things that 
should be taken into account are:
1) functions marked as 'optnone' should never be considered as potential 
candidates for inlining;
2) the inliner shouldn't try to inline a function if the call site is in a 
'optnone' function.

Point 1 can be easily achieved by simply pushing attribute 'noinline' on 
the list of function attributes if 'optnone' is used.
point 2 however would probably require to teach the Inliner about 
'optnone' and how to deal with it.

As in the case of 'alwaysinline' and 'inlinehint', I think 'optnone' 
should also override 'optsize'/'minsize'.

Last (but not least), implementing 'optnone' would still require changes 
in how optimizations are run on functions. This last part is probably the 
hardest part since the current optimizer does not allow the level of 
flexibility required by 'optnone'.  It seems it would either require some 
modifications to the Pass Manager or we would have to make individual 
passes aware of the attribute.  Neither of these solutions seem 
particularly attractive to me, so I'm open to any suggestions!

Thanks,
Andrea Di Biagio
SN Systems - Sony Computer Entertainment Group


**********************************************************************
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify postmaster at scee.net
This footnote also confirms that this email message has been checked for 
all known viruses.
Sony Computer Entertainment Europe Limited
Registered Office: 10 Great Marlborough Street, London W1F 7LP, United 
Kingdom
Registered in England: 3277793
**********************************************************************

P Please consider the environment before printing this e-mail