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

[Nick Lewycky]

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.

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