Updated mangling specs

[Jim Dehnert]

> From jason at casey.cygnus.com  Thu Feb 17 00:30:36 2000
> 
> dehnert at baalbek.engr.sgi.com (Jim Dehnert) writes:
> 
> > > > Also, to allow cross-.o file inlining, you need to extend that to
> > > > any function (not only those explicitly marked inline.) Strictly
> > > > speaking, this is outside the ABI, but unless there are strong
> > > > reasons not to, I'd advocate mangling any static data, regardless of
> > > > whether the function is tagged inline or not.
> > > 
> > > We should mangle the static data for any function that may be inlined;
> > > which functions those are depends on the compiler.
> > 
> > I don't think that we can or should require that the static data
> > always have mangled symbols emitted -- that should be the responsibility
> > of an implementation that chooses to inline routines not declared
> > inline.  However, once the compiler chooses to emit them, it should use
> > the defined mangling for inline routines.
> 
> I'm not sure that we're disagreeing here.

Perhaps not.

> If the compiler decides to inline the function in one translation
> unit, and not in another, we still need to share statics between
> inline and out-of-line copies.  Either we can say that the compiler
> should recognize that the function might be inlined in another TU and
> mangle the locals accordingly, or we can say that we should always
> mangle locals.  The latter might be the only way to deal with inlining
> differences between implementations...if we care.

My concern is that I think ending up with all statics resulting in
external symbols would be bad in terms of bloat and link speed.  So,
I'm willing to sacrifice guaranteed inlining compatibility between
implementations except for routines declared inline.  However, as long
as we've defined the mangling for the cases declared inline,
implementations that follow it when they do inline (or based on a
compile option) would match and work together fine.

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272