This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Thu, Dec 15, 2016 at 10:10:31PM +0100, Jan Hubicka 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 think you also want to disable optimizations we do about local functions
> (stack alignment propagation, calling convention changes), IPA-SRA, IPA-PTA and
> possibly ipa-split.

ipa-split should be turned off by noinline, ipa-sra by noclone, shouldn't
it?  I'll need to write testcases anyway and want to go through my as well
as your list (perhaps find testcases we have for the various optimizations
and make sure that with noipa they don't apply).

> If you want it to be bi-directional it is also necessary to prevent inlining
> into the function with attribute and similarly avoiding other results of IPA
> analysis.

The intent has been that the optimization boundary would be just on the edge
between callers and callee where callee has noipa attribute, so it is fine
to inline anything into the noipa function etc.; if one wants to avoid that,
he would declare those other functions noipa as well.
Otherwise the attribute would be less useful for the GCC testsuite - in many
cases we have
static inline ... fn1 (...) { ... }
__attribute__((noinline, noclone)) ... fn2 (...) { ... fn1 (...); ... }
int main () { ... fn2 (...); ... }
and we rely on the inlining into fn2, but don't want it inlined into main
nor all the other ipa opts.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]