PR 23551: why should we coalesce inlined variables?

[Alexandre Oliva]

On Jul  8, 2007, Jan Hubicka <hubicka@ucw.cz> wrote:

> I think it could work well enough if we was just collecting for each
> variable list of other variables that has been coalesced into it.

It doesn't.  Multiple variables may share the same value at a certain
spot, and diverge later.  Consider this:

0:
  bar = <expr>;

  ... lots of code ...

1:
  foo = bar;

  ... lots of code ...

2:
  bar++;
3:
  foo--;

  ... lots of code ...

You see, from 1 to 2, foo and bar hold the same value, but before
that, foo had a different value, and from 2 on, bar has a different
value.

Now, if we were to use anonymous SSA values and annotations to refer
to variable names, rather than variable versions, we'd have something
like this in a single basic block:

0:
  /* bar = */ value_1 = <expr>;

  ... lots of code ...

1:
  /* foo = */ value_2 = value_1;
  
  ... lots of code ...

2:
  /* bar = */ value_3 = value_1 + 1;
  /* foo = */ value_4 = value_2 - 1;

which could eventually be optimized to:

0:/* bar = */ value_1 = <expr>;
  ...
1:/* foo = value_1; */  // foo and bar can share the same spot here
  ...
2:/* bar = value_1 + 1; */ // but not any more
  /* foo = value_1 - 1; */

So you (hopefully) see using variable names as part of SSA names is
just a distraction that hampers optimization.  There's no codegen
reason to retain any resemblance whatsoever between SSA names and user
variables, just like there's no codegen reason to retain any
resemblance between user variables and registers or stack slots
they're assigned to.  These are only simplifying conventions that
enable us to emit some useful debug information while still generating
reasonable code.

I think we may have to revisit this decision if we want to get better
optimization and also to emit better debug info, and enabling the
disentanglement between SSA names and user variables would be a step
in this direction.

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