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

[Xinliang David Li]

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

Not address exposed static functions.

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

David


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