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

[Andrea_DiBiagio at sn.scee.net]

Hi Nick,

> From: Nick Lewycky <nicholas at mxc.ca>
> > 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).

Right, module passes are a difficult case. 
I understand your point. I think ignoring the `noopt' attribute (or 
whatever we want to call it) may be the best approach in this case: it 
avoid the problems you describe but should still be sufficient for the 
purposes we care about. I am currently studying the module passes in more 
details to be certain about this.

Thanks for the useful feedback,
Andrea Di Biagio
SN Systems - Sony Computer Entertainment Group

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


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