On Thu, 15 Dec 2016, Jakub Jelinek wrote: > So here is a proof of concept of an attribute that disables inlining, > cloning, ICF, IPA VRP, IPA bit CCP, IPA RA, pure/const/throw discovery. > Does it look reasonable? Anything still missing?
I'd like to suggest some additions to the extend.texi entry: > --- gcc/doc/extend.texi.jj 2016-12-15 11:26:07.000000000 +0100 > +++ gcc/doc/extend.texi 2016-12-15 12:19:32.738996533 +0100 > @@ -2955,6 +2955,15 @@ asm (""); > (@pxref{Extended Asm}) in the called function, to serve as a special > side-effect. > > +@item noipa > +@cindex @code{noipa} function attribute > +Disable interprocedural optimizations between the function with this > +attribute and its callers, as if the body of the function is not available > +when optimizing callers and the callers are unavailable when optimizing > +the body. This attribute implies @code{noinline}, @code{noclone}, > +@code{no_icf} and @code{used} attributes and in the future might > +imply further newly added attributes. 1. I believe the last sentence should call out that the effect of this attribute is not reducible to just the existing attributes, because suppression of IPA-RA and pure/const discovery is not expressible that way, and that is actually intended. Can this be added to clarify the intent: However, this attribute is not equivalent to a combination of other attributes, because its purpose is to suppress existing and future optimizations employing interprocedural analysis, including those that do not have an attribute suitable for disabling them individually. (and perhaps remove ' ... and in the future might imply ...' from the quoted snippet, because the clarification makes it partially redundant) 2. Can we gently suggest to readers of documentation that this was invented for use in the GCC testsuite, and encourage them to seek proper alternatives, e.g.: This attribute is exposed for the purpose of testing the compiler. In general it should be preferable to properly constrain code generation using the language facilities: for example, using separate compilation or calling through a volatile pointer achieves a similar effect in a portable way [ except in case of a sufficiently advanced compiler indistinguishable from an adversary ;) ] Thanks. Alexander