This is the mail archive of the
mailing list for the GCC project.
RE: Register Rematerialization In New Register Allocator
- From: Michael Matz <matz at suse dot de>
- To: "Mukta Punjani, Noida" <muktap at noida dot hcltech dot com>
- Cc: Denis Chertykov <denisc at overta dot ru>, <gcc at gcc dot gnu dot org>
- Date: Tue, 1 Jul 2003 13:16:28 +0200 (CEST)
- Subject: RE: Register Rematerialization In New Register Allocator
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.