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

[jahanian]

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.
- 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

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