This is the mail archive of the gcc@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: Beginner's question:Are there any inter-procedural optimizationin GCC backend ?


Geoff Keating <geoffk@geoffk.org> writes:

> "Zack Weinberg" <zack@codesourcery.com> writes:
>> 
>> 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'.)

Yeah, I remember this one.  I don't have a good answer to the
semantics question off the top of my head.  I will observe, though,
that if unit-at-a-time mode is always used there is no difficulty
implementing whatever semantics we feel like implementing.

>> 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'.

Yeah, nested functions are an additional headache, although they'll be
less so if Richard gets his cunning plan implemented.

>>  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.

This, I think, is a red herring.  There is no intrinsic reason why
decode_addr_const should have to talk about RTL *at all* -- it's just
that a SYMBOL_REF is a convenient way to pass an assembly label
around.  It does have to be changed - but it shouldn't be too hard.

zw


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