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: [RFA] __attribute__((inline_everything)) 2nd try

On 14 May 2003, Alexandre Oliva wrote:

> On May 14, 2003, Richard Guenther <> wrote:
> > Ok, thanks - all lookup_attribute() calls deal with warnings only, so I
> > suppose I can ignore those. The inlining decision itself is done via
> > DECL_UNINLINABLE - I suppose setting this is enough. I'll try.
> Make sure to warn if you find this attribute after we already
> generated code for the function.

I dont understand this - as we're not inlining the function itself, the
attribute should be available at the time of code generation, no?

> >> I still think the name is ugly ;)
> > Me too ;) But I didnt manage to find a better one, yet.
> How about inline_barrier or inline_boundary?
> They kind of convey the notion that the function itself shouldn't be
> inlined, and, in a weaker way (ok, not at all :-), that other
> functions are inlined into it.

Its not really a barrier as it is implemented now. Consider

void __attribute__((inline_everything)) foo() { ... }
void __attribute__((inline_everything)) bar() { foo(); }

At the moment we _do_ inline foo() into bar - only if foo() is marked
__attribute__((noinline)) it is an inline barrier, too, and this inlining
is not happening.

I did this on purpose, as I have code that generates math kernels from
different points of abstraction, so I can put an
__attribute__((inline_everything)) to any entry of that chain.

I think naming it "flat" would name it correctly, but I associate flat
with something related to segmentation models...


Richard Guenther <richard dot guenther at uni-tuebingen dot de>

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