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

[jahanian]

Wouldn’t implementing this proposal be a red herring? By this I mean, it is possible that
throughout the optimization phases, there is an implied assumption that all functions
are similarly optimized. An example would be under certain optimization flag, compiler changes 
calling convention of static functions. 

- Fariborz

On Jun 17, 2013, at 8:58 AM, Andrea_DiBiagio at sn.scee.net wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130617/16e8aae4/attachment.html>