PR 23551: why should we coalesce inlined variables?

[Richard Guenther]

On 7/9/07, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jul  9, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:
>
> > I suggested to have a on-the-side mapping (you need it for each
> > function), like a hashtable that maps the SSA_NAME version to a list
> > of user-visible DECLs.
>
> I don't think it's that simple.  Consider the example I gave at
> http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00738.html
>
> How do you envision it to work with an on-the-side mapping?  I don't
> see how it could work, but I'd love to be proven wrong, because it
> would indeed make my current assignment much simpler.

If you have a list of variables per SSA_NAME then that problem is non-existant.
SSA_NAMEs have exactly one definition and as such an exactly defined set
of user variables they refer to.  Of course you need to preserve this mapping
across out-of-ssa, which is where this 1:N mapping becomes M:N.  The idea
would be to transition the 1:N SSA_NAME to VAR_DECL to a
assignment to VAR_DECL mapping which is where you have to do some propagation
for the extra copies out-of-ssa is creating (I guess this is what
Danny refered to).
Then you need to translate the mapping at rtl expansion time as assignments
are expanded to sets of pseudos.  Then preserve this mapping across rtl
optimization passes and finally at the point var-tracking is invoked
now make use
of the mapping.

Your task isn't simple.  But it certainly won't get more difficult
with an on-the-side
table I believe.

A thing that would make it somewhat easier is if we could do expansion out of
SSA form.  That would leave you with translating the 1:N mapping to a mapping
from (set regN) to vars.

Richard.