Re: PR 23551: why should we coalesce inlined variables?

[Alexandre Oliva <aoliva at redhat dot com>]

On May 10, 2007, Jan Hubicka <hubicka@ucw.cz> wrote:

>> 
>> It might also be possible to 'save' the original name in a table, and if
>> a useful coalesce was not performed at out of ssa time, rename the
>> variable back, or choose the most 'useriest' name amongst a coalesce
>> group... That might also help debug info a bit.

> Note that there is similar issue in inliner itself when it replaces SSA
> name representing parameter by the SSA name passed to function
> discarding any mention of the inlined function parameter from debug
> info.

Yup.  But that doesn't make any actual difference, except perhaps for
-O0.  I experimented taking that out, and copy-prop would take care of
replacing all uses of the LHS of this initial assignment with the RHS.

Once we come up with strategies to cope with multiple debug names for
the same gimple variable (such that perhaps different SSA versions can
have different user-visible names associated with them), then we can
worry about this minor detail.

> Not coalescing across inline copies is really going to give big
> performance degradation for thinks like tramp3d.

Can't such performance degradation hit in non-inline cases as well?
I.e., is this not an argument for doing away not only with the
DECL_FROM_INLINE tests, but with the whole notion of "don't coalesce
this because it's user visible"?

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}