Re: [RFC] noipa attribute (was Re: How to avoid constant propagation into functions?)

[Alexander Monakov <amonakov at ispras dot ru>]

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