This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [rfc] Whole program optimization
>
> 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