Re: [PR64164] drop copyrename, integrate into expand

[Alexandre Oliva <aoliva@redhat.com>]

On Aug  5, 2015, Richard Biener <richard.guenther@gmail.com> wrote:

> It was just a hunch when you talked about BLKmode and params in memory.
> As coalescing is about SSA name (thus register) coalescing I was thinking
> that if you coalesce a register with incoming memory you'll end up with
> more memory accesses?

Since we only coalesce variables whose promoted mode is the same, if one
of them gets BLKmode and has to live in memory, so would all the others
it might coalesce with.  So, even though we have gimple_regs, we can't
have pseudos.  This was observed with vector types for which no native
vector mode is available.

It would still make sense to share them when possible, to reduce the
number of mem-to-mem copies.  And we don't want to copy incoming BLKmode
parms to *another* memory location if we can help it.

Now, maybe you're concerned about incoming parms passed by reference
that *can* be held in pseudos.  For those, we will perform a load from
memory to a pseudo and use that, even if the pseudo ends up allocated in
memory.

> I also thought of the RTL expansion thing we do with at first copying
> the hardreg incoming args to pseudos and how that interacts with
> coalescing.

Most of what changed now is who gets to choose the pseudo; it used to be
assign_parms, now it's cfgexpand.  The other significant change is that
now, when cfgexpand detects a BLKmode parm, it will choose MEM, but it
won't set up the address, so that assign_parms still does what it used
to, namely, copy the incoming hard reg to a pseudo, and then use the
pseudo as the MEM address.

> But I guess you have eyed code-gen changes a bit anyway.

Yeah.  Not much has changed in the before parm_birth area; expected
changes have to do with the pseudo numbering.  IIRC, anything else would
be unexpected.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer