Re: [rfc] Whole program optimization

[Jan Hubicka <jh at suse dot cz>]

> 
> On 27/05/2005, at 2:08 PM, Jan Hubicka wrote:
> 
> >>On Thu, May 26, 2005 at 06:46:33PM -0700, Geoffrey Keating wrote:
> >>
> >>>>I remember that we discussed this with Richard while past and  
> >>>>Richard
> >>>>argued that ELF visibility flags should be used instead.  I  
> >>>>don't have
> >>>>archive of the disucssion and I am not quite convinced that this is
> >>>>possible (this is quite ortoghonal issue to the visibility outside
> >>>>linked object), so if I miss something here, please enlighten me.
> >>>>
> >>>
> >>>I believe that the idea here was that instead of
> >>>__attribute__((used)), you would use
> >>>__attribute__((visibility("default"))) or
> >>>__attribute__((visibility("hidden"))) or
> >>>__attribute__((visibility("protected"))).  That is, this new  
> >>>functionality
> >>>would be equivalent to saying -fvisibility=internal.
> >>>
> >>
> >>Indeed.  The point is that we have existing options to control
> >>visibility of symbols.  We do not need another.
> >>
> >
> >This seem to have two problems.  You will have to put __attribute__
> >construct to expocitly mark main() and you need ELF system to allow  
> >the
> >-fvisibility flag.
> >I can take care to make -fvisibility=internal functionally  
> >equivalent to
> >-fwhole-program on systems where it works (except for main()) but I
> >would preffer to have separate flag for this so sources don't need  
> >to be
> >modified like most of other compilers seems to have - I would guess  
> >this
> >is what users expect, not only to make it possible for using for SPEC
> >build..
> 
> Make the default for main() be that it does not get 'internal'  
> visibility, just as your patch would have made it not be 'static'.
> 
> There is nothing specifically ELFish about -fvisibility.  For  
> instance, Darwin supports 'hidden'.  Since 'internal' would be  
> implemented completely inside the compiler, it can work on every system.

OK, currently -fvisibility=internal works only on ELFish targets and
imply the .internal linkage to be output to assembly.  So you suggest
that it should be changed to be equivalent of what -fwhole-program does
(ie instead of doing .internal, it should simply make the symbols local
on all targets probably by removing the DECL_PUBLIC flag as I do now and
made visibility=default support unconditional on all targets too) and we
should change the behaviour in a way that we will ignore linkage of main
function (do we want to change the behaviour for other visibilities
too?).

I am not quite sure how we want to get this working without
-funit-at-a-time as probably mangling DECL_PUBLIC flag before frontend
is done with it's job is not good idea, but perhaps it is time to kill
-fno-unit-at-a-time completely at last or for a moment simply make the
two options incompatible sounds resonable to me too.

Last thing I am not sure about is what we want to do with C++ linkonce
stuff (with -fwhole-program it still stays public so linking with
libraries works as expected, but I guess this is the same for
visibilities, as the visibility gets overwritten to weak, right?)

OK, if this sounds like way we want to go, I will break out the bits
from my current patch so unit-at-a-time gets internal visibility symbols
handled very same way as I do right now for public symbols (ie not
consider them externally visible and remove the DECL_PUBLIC flag later
in the game) and as a followup I will try to make the
-fvisibility=internal working with unit-at-a-time compiliations.

Sounds sane?
Honza