This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR 23551: why should we coalesce inlined variables?
On Thu, 2007-06-28 at 00:18 -0700, Seongbae Park (ëìë, ææå) wrote:
> On 6/27/07, Alexandre Oliva <aoliva@redhat.com> wrote:
> > Sorry that it took me so long to get back to this.
> This is not to say I object to your patch - rather I'm flabbergasted
> than anything that disabling coalescing at gimple has such a low impact -
> I have to wonder if there's other passes that coalesce names later
> (or if RTL level coalescing/register assignment makes the lack of tree level
> coalescing less of a problem).
There is *lots* of coalescing that does happen, especially among
compiler temporaries.
This pass doesn't ACTUALLY do coalescing. Coalescing can only happen
between 2 ssa-names with the same base variable. This pass looks for
copies between ssanames with different bases, and decides to rename one
of the bases so that it might be possible to coalesce them later.
That doesnt mean they will be coalesced however. Thats why we don't go
around renaming 2 user variables. if a_6 and b_8 are both user
variables, that would allow b_8 to be changed to a_8, hoping they can
both be coalesced to 'a' later. If they don't coalesce, you will end up
with 'a' and 'a.1', or some such thing. Meaning you have now LOST
information instead of gaining information because 'b' has vanished off
the face of the earth for no good reason.
We were ignoring this restriction if at least one of the user variables
was an inlined name, and thats the restriction being removed here.
Inlining is done differently now than it was back then, so it may not be
as bad now as it was then.
I fooled around with some simple cases, and didn't find anything that
made much difference. Whats a testcase you have which shows this
helping?
Andrew