Re: [PR64164] drop copyrename, integrate into expand

[Alexandre Oliva <aoliva@redhat.com>]

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

> Though I wonder on whether splitting the patch into a first one with disabling
> coalescing of parms (their default defs(?)) and a followup implementing the
> support for that.

We can't disable coalescing of parms altogether.  With -O0, we must
coalesce all SSA_NAMEs referencing each parm to a single partition.
With optimization, we could coalesce parms in general, just not these
special cases in which the parm is to live in a caller-supplied memory
block.

Now, it's not coalescing parms proper that brought so much risk to the
patch, it is assigning rtl to SSA partitions, and having assign_parms*
use that assignment.  Considering that sometimes a single param
necessarily ends up in more than one partition, requiring two
assignments, and that assign_parms* can't deal with that, I don't see
how to easily disable the cfgexpand logic when it comes to parms, so as
to be able to leave assign_parms alone.

How about, if further problems arise that justify reverting the patch
one more time, I'll look into splitting the patch as you suggested, but
otherwise, I'll save myself the trouble, ok?

> So - is my observation correct that this is only about coalescing of the
> default defs of parameters, not other SSA names based on parameter decls?

It's more like the opposite, i.e., we *refrain* from coalescing other
SSA_NAMEs related with byref params, so that we can easily tell when a
partition references a byref param and whether that partition holds its
default def.  We could have coalesced any other names that ended up in
different partitions, and even the partition holding the default def, if
we had other means to identify partitions with default defs of byref
params.  For example, we could create a bitmap of byref param default
def versions, and then, after partitioning, map those to the partitions
they were assigned to.  In fact, I might do that as a followup.

> Do you think this splitting is feasible and my concern about the
> code-gen issues warranted?

It is feasible but not exactly easy.

As for codegen, I hope to have covered all cases now, but should we find
out I haven't, I'll try the split and see what that gets us.  Did you
have any special cases in mind that it looks like I may have missed?

Thanks,

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