Re: ELF interposition and One Definition Rule

[Jan Hubicka <hubicka at ucw dot cz>]

> > 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