Re: Some cleanups for the tree inliner.

[Steven Bosscher <s dot bosscher at student dot tudelft dot nl>]

Op vr 01-08-2003, om 13:49 schreef Jan Hubicka:
> > This patch modifies the behavior of the compiler in two different ways:
> > - It adds warnings to tell the user that functions calling alloca
> >   or __builtin_longjmp (ie. using sjlj exceptions) cannot be inlined. 
> >   This means that the user now first gets a warning about this, and
> >   then another warning for each place where inlining failed.
> Perhaps we can avoid a warning second time.

I wasn't sure if that was the right thing to do.  Personally I would
like to see where inlining of an `inline' function fails, even if it
fails because I wrote uninlinable code.  So I decided to keep that
warning for all functions that fail to inline, for whatever reason.

> In theory UNINLINABLE flag can be set only when such things are done as
> checking overflow of inlining limits is cheap.  So only

In fact that is what we always have done.  DECL_UNINLINABLE is only set
for truely uninlinable functions.  Previously, inlinable_function_p
would return false if the limits prevented inlining, but this wasn't
recorded in DECL_UNINLINABLE (because obvioulsy a function can be
inlinable elsewhere). 

> inlibable_function_p would play with UNINLINABLE patch and
> limits_allow_inlining would be used each time when unit-at-a-time is not
> in action. (unit-at-a-time should not use it at all now, right?)

It is easy to avoid the second warning: Check for DECL_UNINLINABLE in
expand_call_inline() and don't warn if it is set.

> > - It fixes the throttle to take into account the difference between
> >   MAX_INLINE_INSNS_SINGLE and MAX_INLINE_INSNS_AUTO.  This is a bug
> >   in the current inliner that allows auto-inlining functions larger
> >   than MAX_INLINE_INSNS_AUTO when throttling.
> In non-unit-at-a-time, right?

Yes, because in unit-at-a-time we never throttle, so
limits_allow_inlining is never called.

Gr.
Steven