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

I do have patches for both making the testcase rejected or accepted in
the queue and would really like to see this resolved.

The major problem with rejecting the cases above is that at least glibc
does commonly contain such a code, just with the presence of extern
inline functions (it first includes headers and then renames
everything).
So the first alternative is really not a alternative in case we want to
keep glibc compiling in it's current form.

Glibc also uses renaming via typeof construct where the argument of
typeof counts as use.

So the definition of usefull and weird is very tricky here.

The other sollution is not terribly hard.  Perhaps we can live with it
and simply issue warning when the symbol name has been already assembled
before renaming to notify user about funny semantics in
non-unit-at-a-time.

Honza
> 
> >> 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]