Re: HPPA constructor merge patch, PR middle-end/45388

[Jan Hubicka <hubicka at ucw dot cz>]

> On 09/27/2010 02:05 PM, Steve Ellcey wrote:
> > When I look at the code, I see that _GLOBAL__I__ZN2c12f6Ev is never
> > (directly) called by anything but it calls
> > _Z41__static_initialization_and_destruction_0ii, which
> > _GLOBAL__I_65535_0__ZN2c12f6Ev also calls.  Is _GLOBAL__I__ZN2c12f6Ev
> > the old (premerged) constructor that should no longer be used and has
> > been replaced by GLOBAL__I_65535_0__ZN2c12f6Ev?
> 
> Yes.  I believe that the expected full sequence is that 
> 
>   GLOBAL__I_65535_0__ZN2c12f6Ev calls
>     GLOBAL__I__ZN2c12f6Ev calls
>       _Z41__static_initialization_and_destruction_0ii
> 
> and that GLOBAL__I__ZN2c12f6Ev got inlined.
> 
> > But if
> > it has essentially been replaced, why wasn't it just removed entirely?
> 
> An excellent question.  I wonder if it's still marked
> as preserved or something?
> 
> Of course regardless it seems like we're absolutely
> relying on that middle call being inlined and eliminated.
> I can think of two solutions: adjust collect2 to ignore
> local symbols, or rename the middle function so that it
> no longer matches the collect2 pattern.  Both solutions
> seem slightly unpleasent, actually.
> 
> Thoughts, Jan?

The code was setting disregard inline limits.  This is wrong as constructors
might contain stuff that is not really inlinable (and on LTO we might just blow
ourselves off by constructing overly huge functions).

I will take a look why it is not getting inlined in this particular case.  We might
just run off the large function growth limits or something.

But indeed I don't think we should have correctness depending on fact whether
we decided to inline or not.  My plan was to teach collect2 to ignore static symbols.
I didn't get to do that for a while, that is moslty because I am not terribly familiar
with the code and there was always always other problems to look into, but this seems
like correct solution to me.

Honza
> 
> 
> r~