Re: Lazy allocation of DECL_ASSEMBLER_NAME

[Geoff Keating <geoffk at geoffk dot org>]

Mark Mitchell <mark@codesourcery.com> writes:

> Geoff Keating wrote:
> 
> >>Yes.  I have partial code implementing this.  The fiddliest part is
> >>the nontransitive type comparison problem that Dale is encountering.
> >>I personally think that the front end should go to whatever lengths
> >>are necessary to present just one type to the language-independent
> >>compiler, even across multiple translation units, even in the presence
> >>of a nontransitive type system.  I think this is easier than it might
> >>sound - the trick I have in mind is permuting TYPE_MAIN_VARIANT so
> >>that it's always the appropriate choice for *this* translation unit.
> >>
> >
> >It might be difficult to determine which translation unit is "this
> >unit" at any given point; you might have code that does:
> >
> There are lots of things that are hard about inter-module analysis, as
> you of course know. :-)

By 'difficult' I meant 'impossible and also conceptually wrong'.

Inter-module analysis is very simple.  Trying to change decl handling
in the compiler without thinking about the consequences of
inter-module analysis: that's hard.

> It's an inherent design problem: we're essentially trying to combine
> multiple C translation units into a single C translation unit, and C
> is not a language that permits that.

I'm not trying to make a single C translation unit.  I'm not sure that
is a good idea, or is even possible.  I don't recommend anyone try it;
I think it's not a productive design direction.

What I did to implement IMA is to make the compiler handle multiple
translation units in the same process.

>  Most object file formats are
> designed to support C, so we see these problems at that level too.
> For example, in the past, I've complained about the fact that if we
> have two static functions with the same name in different translation
> units, the single .o that we generate renames them.
> 
> In the example that you give, the program is not conforming if the
> definitions of "struct foo" are not identical across translation
> units.  (Or, at least, that would be true in ISO C++.  It might not
> have to be true in ISO C.  You may know more than I.)  In any case, if
> the structures do not match up across the translation units, we should
> just not combine them.  That is certainly not the common case.

C is very very different from C++ for the purposes of IMA.  In C++,
types have linkage, there is the one definition rule, and there are no
'tentative definitions'.  IMA for C++ will look quite different.

I'm not sure what you mean by 'just not combine them'.  (I'm not sure
which "them" you're referring to, structures or TUs, and I'm not sure
what "combine" means in this context.)

> We'll likely break some aspects of inter-module optimization when we
> fix some of the single translation-unit issues.  That is what we get
> for collectively not agreeing on a single development plan.

I worry when I see statements like this.  I presume that by "break",
you mean that "while working on these patches, some things will break,
but of course those will be fixed before any patch is actually checked
in, or as soon as possible afterwards if we didn't notice them before
checkin", correct?

Breaking IMA means that it's hard to get meaningful SPEC numbers,
which means that some people can't work on GCC until the problem is
fixed.

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