[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto

[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |d.g.gorbachev at gmail dot
                   |                            |com

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-01 10:20:47 UTC ---
*** Bug 47934 has been marked as a duplicate of this bug. ***

[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038

--- Comment #8 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2011-03-01 12:46:39 UTC ---
> The problem is that statics need to be mangled, so they persist
> as i.1234 instead.  Really refering to a local symbol in asm is
> going to be difficult with LTO (any global or other static symbol
> with name i will cause a non-resolvable conflict).

One solution is to introduce a new attribute, say "nomangle", and shift
responsibility for possible conflicts on a user.

[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038

--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-03-01 16:39:23 UTC ---
On Tue, 1 Mar 2011, d.g.gorbachev at gmail dot com wrote:

> > The problem is that statics need to be mangled, so they persist
> > as i.1234 instead.  Really refering to a local symbol in asm is
> > going to be difficult with LTO (any global or other static symbol
> > with name i will cause a non-resolvable conflict).
> 
> One solution is to introduce a new attribute, say "nomangle", and shift
> responsibility for possible conflicts on a user.

The original LTO proposal included assembler changes to allow multiple 
local symbols with the same name in the output.  You could resurrect that, 
though allowing references to the multiple local symbols from asm imposes 
extra requirements on what the assembler interface must look like 
(directives to say which versions are being referred to by asms in a 
particular part of the input?).

[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038

--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-01 16:42:26 UTC ---
(In reply to comment #9)
> On Tue, 1 Mar 2011, d.g.gorbachev at gmail dot com wrote:
> 
> > > The problem is that statics need to be mangled, so they persist
> > > as i.1234 instead.  Really refering to a local symbol in asm is
> > > going to be difficult with LTO (any global or other static symbol
> > > with name i will cause a non-resolvable conflict).
> > 
> > One solution is to introduce a new attribute, say "nomangle", and shift
> > responsibility for possible conflicts on a user.
> 
> The original LTO proposal included assembler changes to allow multiple 
> local symbols with the same name in the output.  You could resurrect that, 
> though allowing references to the multiple local symbols from asm imposes 
> extra requirements on what the assembler interface must look like 
> (directives to say which versions are being referred to by asms in a 
> particular part of the input?).

I think we settled on the idea to delay mangling of local symbols until after
we composed ltrans units (so we can also compose units in a way to avoid
the need to mangle local symbols with a used attribute).  It shouldn't be
too difficult to implement but sofar nobody has done the work (and it
will likely be easier with a global symbol table which we hopefully will
get for 4.7).

[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038

--- Comment #11 from Jan Hubicka <hubicka at ucw dot cz> 2011-03-01 17:41:48 UTC ---
> > The original LTO proposal included assembler changes to allow multiple 
> > local symbols with the same name in the output.  You could resurrect that, 
> > though allowing references to the multiple local symbols from asm imposes 
> > extra requirements on what the assembler interface must look like 
> > (directives to say which versions are being referred to by asms in a 
> > particular part of the input?).

Hmm, doing that would imply need to refer to the static in some global way
anyway. When it is referenced from regular code and two static variables from
two different units might end up in the same instruction.
Not too hard to implement I guess.
> 
> I think we settled on the idea to delay mangling of local symbols until after
> we composed ltrans units (so we can also compose units in a way to avoid
> the need to mangle local symbols with a used attribute).  It shouldn't be
> too difficult to implement but sofar nobody has done the work (and it
> will likely be easier with a global symbol table which we hopefully will
> get for 4.7).

I do not like much the idea of improsing new artificial limits on the
partitioning. Once we start doing fancy stuff at the ltrans time, we will
have hard time partitioning the important stuff into single partition.  Those
extra requirements would just make it harder

I probably like most the variant with extending the asm syntax for
inputs/outputs at toplevel statements (like Sun compiler seems to do already)
and declaring direct references to statics not LTO compatible.

It seems much cleaner to me to declare that variable is used at the place it is
actually used rather than annotating the declaration. Also it avoid the need
for asm statement to be aware of target mangling rules (i.e. prefixing with _)

Honza

[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038

--- Comment #12 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-02 10:16:12 UTC ---
(In reply to comment #11)
> > > The original LTO proposal included assembler changes to allow multiple 
> > > local symbols with the same name in the output.  You could resurrect that, 
> > > though allowing references to the multiple local symbols from asm imposes 
> > > extra requirements on what the assembler interface must look like 
> > > (directives to say which versions are being referred to by asms in a 
> > > particular part of the input?).
> 
> Hmm, doing that would imply need to refer to the static in some global way
> anyway. When it is referenced from regular code and two static variables from
> two different units might end up in the same instruction.
> Not too hard to implement I guess.
> > 
> > I think we settled on the idea to delay mangling of local symbols until after
> > we composed ltrans units (so we can also compose units in a way to avoid
> > the need to mangle local symbols with a used attribute).  It shouldn't be
> > too difficult to implement but sofar nobody has done the work (and it
> > will likely be easier with a global symbol table which we hopefully will
> > get for 4.7).
> 
> I do not like much the idea of improsing new artificial limits on the
> partitioning. Once we start doing fancy stuff at the ltrans time, we will
> have hard time partitioning the important stuff into single partition.  Those
> extra requirements would just make it harder
> 
> I probably like most the variant with extending the asm syntax for
> inputs/outputs at toplevel statements (like Sun compiler seems to do already)
> and declaring direct references to statics not LTO compatible.
> 
> It seems much cleaner to me to declare that variable is used at the place it is
> actually used rather than annotating the declaration. Also it avoid the need
> for asm statement to be aware of target mangling rules (i.e. prefixing with _)

Well we can still simply not mangle a static if it is marked used and
all conflicting decls are not used and also static.  Likewise not mangle
a static if there are no conflicts.  I consider this a QOI issue also
with regard to debugging.  This would be just delaying the mangling until
WPA stage (symbol merging), not ltrans stage.

It wouldn't fix the case with two conflicting used vars but it probably
would catch most real-world cases.

Richard.

> Honza

[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038

--- Comment #13 from Jan Hubicka <hubicka at ucw dot cz> 2011-03-02 16:32:20 UTC ---
Not mangling statics unless conflict is found is indeed desirable QOI thing. 
It makes assembly and other things look
a lot more smoother than it does now.

Honza

[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038

--- Comment #14 from Jan Hubicka <hubicka at ucw dot cz> 2011-03-02 16:34:22 UTC ---
Ah, the reason for writting reply was primarily the observation that enforcing
partitioning based on origin of asm statement won't fly with crossmoudle
inlining, so I think it is quite useless complication of the whole thing.

Also the not mangling unless we hit conflict probably should be implemented
in a way that when conflict exists all static of same name are renamed, so
asm statements won't compile rather that end up referring random other
variable.

Honza

[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038

--- Comment #15 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-02 16:39:09 UTC ---
(In reply to comment #14)
> Ah, the reason for writting reply was primarily the observation that enforcing
> partitioning based on origin of asm statement won't fly with crossmoudle
> inlining, so I think it is quite useless complication of the whole thing.

Well, with a used global local decl I would just leave the unit alone,
doing a 1:1 partition for it (not mangling it).  That way we can even
handle multiple conflicting used declared statics ...

Of course that's the same end-result as if the user would compile the
unit without -flto.

Not sure if it's worth going that way though.

> Also the not mangling unless we hit conflict probably should be implemented
> in a way that when conflict exists all static of same name are renamed, so
> asm statements won't compile rather that end up referring random other
> variable.

Yes (assuming people forgot to annotate vars with attribute((used))).

We should also consider mangling them according to the function
or TU context, also for easier debugging.  Not sure if this is possible
without running into target limitations though.

Richard.

[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038

--- Comment #16 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-02 16:42:02 UTC ---
(In reply to comment #15)
> (In reply to comment #14)
> > Ah, the reason for writting reply was primarily the observation that enforcing
> > partitioning based on origin of asm statement won't fly with crossmoudle
> > inlining, so I think it is quite useless complication of the whole thing.
> 
> Well, with a used global local decl I would just leave the unit alone,
> doing a 1:1 partition for it (not mangling it).  That way we can even
> handle multiple conflicting used declared statics ...
> 
> Of course that's the same end-result as if the user would compile the
> unit without -flto.
> 
> Not sure if it's worth going that way though.
> 
> > Also the not mangling unless we hit conflict probably should be implemented
> > in a way that when conflict exists all static of same name are renamed, so
> > asm statements won't compile rather that end up referring random other
> > variable.
> 
> Yes (assuming people forgot to annotate vars with attribute((used))).

Of course if there is a conflict with a global (non-local) decl then
the asm will bogously pick that up.  So either way isn't bullet-proof.

Richard.

[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038

--- Comment #17 from Jan Hubicka <hubicka at ucw dot cz> 2011-03-02 16:56:47 UTC ---
> Well, with a used global local decl I would just leave the unit alone,
> doing a 1:1 partition for it (not mangling it).  That way we can even
> handle multiple conflicting used declared statics ...

Well, you would not only require 1:1 partition but prevent inliing functions
containing asm statements posisbly referring used global local decl to
other units.

> Not sure if it's worth going that way though.

I would preffer we do not.  It is ugly. 
> 
> > Also the not mangling unless we hit conflict probably should be implemented
> > in a way that when conflict exists all static of same name are renamed, so
> > asm statements won't compile rather that end up referring random other
> > variable.
> 
> Yes (assuming people forgot to annotate vars with attribute((used))).

I think this won't help, since alias analysis, readonly var discovery and
others
will stand in the way and break code on random basis.  Main benefit IMO is to
reduce the symbol tables and make nm output more readable etc.

> We should also consider mangling them according to the function
> or TU context, also for easier debugging.  Not sure if this is possible
> without running into target limitations though.

You mean something like mylocalstatic.mysourcefile.c?  Possibly, it would make
names noticeably longer obviously.

Honza