This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: ELF interposition and One Definition Rule
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Nathan Sidwell <nathan_sidwell at mentor dot com>, Jason Merrill <jason at redhat dot com>, Jan Hubicka <hubicka at ucw dot cz>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Nathan Sidwell <nathan at codesourcery dot com>, Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Date: Wed, 28 Aug 2013 13:52:11 +0200
- Subject: Re: ELF interposition and One Definition Rule
- Authentication-results: sourceware.org; auth=none
- References: <20130826152141 dot GA19918 at kam dot mff dot cuni dot cz> <521BF9C1 dot 8080806 at redhat dot com> <521CA12C dot 9090604 at mentor dot com> <CAFiYyc0P7nTjLjWEwiNB9nPpM5Dy55GN6OZ1G9Nam1exFjHKxQ at mail dot gmail dot com>
> > I had thought that that case (overriding malloc etc) was what this patch was
> > dealing with. Perhaps I was confused.
> >
> > There's nothing particularly special about ctors, dtors and virtual function
> > implementations. Their common feature, as Jan described, is that it's hard
> > to take their address:
> > * ctors don't have names.
> > * dtors do have names, but you can't take their address.
> > * virtual function implementations can't have their instance address taken
> > -- you get the ptr-to-memfn object describing the vtable slot etc. There is
> > (was?) a GNU extension to work around that, IIRC.
> >
> > So that stops a programmer calling these indirectly. However I don't really
> > see the semantic difference between:
> >
> > fptr = &somefunc; ... fptr (...);
> > and
> > somefunc (...);
> >
> > So treating those 3 types of function specially because you can't use the
> > former syntax with them seems odd.
What is really important for backend is that it is not defined what happens
when you compare addresses of those functions (based on fact that youcan't take
it, as for ctors/dtors, or compare it, as for virtual functions). If backend
also knows that they are not interposable, it knows it can freely duplicate
or unify their bodies when it seems win.
The problem whether we want to promise working interposition on these is
however ortoghonal to whether one can or can not take address of them. I
wonder how much we want to allow by default: my impression is that we pay large
cost to allow occasional rewrite of functions like malloc. As Jason mentioned,
it is really rare to rewrite something implemented in current unit and it is
where 90% of the runtime costs come from.
Adjusting by defualt would be a good win. We can also invent command line flag
for this and ask users to use it often.
>
> Yeah - this is why I'm always worried about "frontend specific" optimizations
> in the middle-end. If you need to rely stuff that's not visible in GIMPLE then
> it smells.
I am not too keen about language specific rules in gimple either (though I introduced
quite some knowledge now for C++ devirtualization - we may think how to make these
more generic if we care about Java/other languages with polymorphic calls).
I have in my TODO to discuss ading extra gimple flag "address of this symbol is
never used for equality comparsion" flag. S far we always tested DECL_VIRTUAL
for this (that is something I learned from ICF presentation of gold) but I am
sure non-C frontends can use it more widely. We can also make early
optimizations /propagation to rule out simple cases where address is taken but
clearly never compared.
Similarly we may want to make frontend to decide on availablity of function in
question instead of having the magic in the cgraph function. But I guess we first
need to figure out what the rules are.
Honza