Re: Beginner's question:Are there any inter-procedural optimization in GCC backend ?

[Geoff Keating <geoffk at geoffk dot org>]

"Zack Weinberg" <zack@codesourcery.com> writes:

> Geoff Keating <geoffk@geoffk.org> writes:
> 
> > "Zack Weinberg" <zack@codesourcery.com> writes:
> >
> >> 2) The RTL inliner is a major obstacle to making all RTL be
> >>    transiently allocated, and therefore to removing RTL from the
> >>    purview of the garbage collector.  Daniel Berlin has numbers
> >>    indicating that allocation of RTL from the GC heap causes huge
> >>    amounts of memory to be wasted, with consequent compile-time
> >>    performance hit.
> >
> > The RTL inliner is not the only obstacle to this.  Many places in the
> > backends and in the middle-end keep references to RTL which they
> > expect to stay around forever. 
> 
> Right.  I think those places are all susceptible to being found and
> fixed, though.  The big open question in my mind is whether DECL_RTL
> can be made just a cached derivative of information elsewhere in the
> DECL, for all DECLs.

I was the last person to try to ensure that.  I believe that this is
now true in every case *except* where the user has explicitly given an
assembler name.  That case should be changed too; there's a bugzilla
report related to it somewhere, about:

extern int foo(void);
int main (void) { foo(); }
int foo (void) asm ("not_really_foo") { ... }

(The question is what this should mean, or if it should be invalid,
and if it's invalid then precisely what is the rule about when you can
declare something like 'foo'.)

> > Usually these things are constants of some form, SYMBOL_REFs or
> > CONST_INTs, but LABEL_REFs are also constant, which is the point at
> > which life becomes complicated.
> 
> CODE_LABELs don't have meaning outside of a given function,

You have to define 'outside' quite carefully: nested functions, for
instance, are not 'outside'.

> except
> insofar as we need to be careful not to duplicate label names, which
> is taken care of by the label_num counter.  And I don't see any
> places where anything holds on to a CODE_LABEL after the insn chain
> for the containing function is thrown away (but I didn't look very
> hard).

You'd have to explain what you mean by 'thrown away'.  Obviously if something
is holding on to a CODE_LABEL, GC won't throw away the body of the function.

>  Could you be more specific about the problem?

I'd look at the first instance of the string CODE_LABEL in
varasm.c.  The tree pool (constant_descriptor_tree) is per-compilation,
not per-routine, and it appears to be able to hold references to
CODE_LABELs via ADDR_EXPRs.

There may also be code like this in the backends.  I've checked that
rs6000 carefully *doesn't* do this for CODE_LABELs (but it does for
any other kind of constant), but I believe that the arm backend also has
special constant pools.

-- 
- Geoffrey Keating <geoffk@geoffk.org>