RE: Register Rematerialization In New Register Allocator

[Michael Matz <matz at suse dot de>]

Hi,

On Tue, 1 Jul 2003, Mukta Punjani, Noida wrote:

> [... you want to remat arbitrary expressions ...]
>
> This is the particular area which I intend to incorporate i.e. pseudo
> handling in case of remat. More comments welcome..

The problems with general expression are:
 a as noted in the comment you posted, the incremental graph builder
   needs to be changed to deal with the changed layout of those webs,
   which are operands of the expressions.  I.e. they need to be
   reconstructed.  For that these webs simply need to be marked when an
   dependent expression was rematerialized.
 b At the point of rematerialization it needs to be prooved, that the
   operands of it 1) are still live and 2) contain the same value they
   had when that expression was first used.
   (1) is necessary to not extend the livetime of the operand webs.
   That's needed because the rematerialization itself was only a result
   of high register pressure (mostly), so extending livetime of even more
   operands is contra productive.
   (2) is obviously necessary, if one doesn't want to deal with the whole
   machinery of lacy code motion, which we don't want.

An easy way to implement b (1 and 2) is to note, that between the uses of
a web, and the definitions of it, no definition of the to be
rematerialized expression occured.  This information is already partly
constructed during construction of the conflict graph.  It's thrown
away currently.  During adding the conflict edges one could add code to
mark these, though.


Ciao,
Michael.