This is the mail archive of the gcc-patches@gcc.gnu.org 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: [RFA] attribute((inline_everything)) (was Re: [RFA] Kill artificialinlining limit)


On Tue, 13 May 2003, Michael Matz wrote:

> Hi,
>
> On Tue, 13 May 2003, Phil Edwards wrote:
>
> > > Which part actually? noinline marks the function as not supposed to be
> > > inlined, inline_everything marks the function to inline all its function
> > > calls.
> >
> > That's not the /most/ unintuitive interface I've ever encountered, but it's
> > very very close.
>
> Call it proof-of-concept.  _I_ can see the use in such an attribute.
> Certainly Richard indeed _has_ a use for it.  That the interface is
> slightly funny is fixable most probably.  Richard gave an explanation for
> that crumpy interface.

Yup. I think such an attribute is orthogonal to the always_inline and
noinline attributes and is quite useful for me and maybe for others, too.

> Richard: Indeed the interface is ugly.  If anything, the existance of the
> flatten_all_calls attribute (I think thats a better though not optimal
> name) should implicitely set the noinline attribute.  Reasoning is like
> yours.

Yes, that sounds better. Unfortunately I cannot get it work as I thought -
with the right combination of attribute((always_inline)) and the removal
of the min-inline-insns cut-off, I previously could get everything inlined
inside my loops. Now with a slightly extended inline_everything attribute
code, I always hit the "function body available" and "langhooks" test in
tree-inline.c:inlinable_function_p(). Though I cannot find code to handle
the always_inline attribute somehow special during f.i. function deferral.

Ho humm...

still trying,
Richard.


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