Re: SSA and implicit uses.

[Michael Matz <matz at suse dot de>]

Hi,

On Tue, 2 Nov 2004, Sanjiv Kumar Gupta wrote:

> > > My compiler generates SSA form like below:
> > >   r200 = 0;
> > >   r201 = r200 + 1;
> > >   r202 = r201 + 1;
> > > 
> Okay. Consider initial value of 'a' as unknown.
> 
> The point is that, when a single var gets splitted
> into mulitple live ranges (and different hard regs
> consequently), the code generated is worse than
> what could have been generated if the original
> var was kept into a single hard reg.

Depends on how you represent the individual insns.  In your example it's
  D = A + B
If you somehow know (in GCC for instance the operand constraints let you 
know this), that it would be good, if D and A are the same registers, you 
can simply coalesce them too (if A dies in the insn), as if it were a 
move.  That's called extended coalescing.

Note, that normally coalescing can fail.  For instance if A doesn't die in 
that insn.  So if your insns _require_ that D and A be the same registers 
you have to emit the necessary moves before hand, i.e.:

  r200 = x
  r201 = r200
  r202 = r201 + 1
  r203 = r202
  r204 = r203 + 1

where the destination of each move is used only exactly once in the 
following insn.  This ensures that A dies, and the coalescing can happen, 
and the fake move will be deleted.

By that follows that you don't really need to explicitely emit these fake 
moves.  You must merely somehow make sure, that the read part of a 
read-mod-write operands dies in the insn.  For most cases which happen 
during SSA formation this is true anyway.  Only those where the operands 
weren't already equal before SSA formation will a real move be required 
(and the coalesce will fail, so you need to deal with that, either by 
emitting such moves before going into SSA, or by fixing up the code after 
allocation, like reload does).


Ciao,
Michael.