Register Rematerialization In New Register Allocator

["Mukta Punjani, Noida" <muktap at noida dot hcltech dot com>]

Hi,

I would like to discuss the register remat(rematerialization) 
in new register allocator branch.
 
During register allocation, when a value cannot be kept in a register and
needs to be spilled, the register allocator should recognize when it is
cheaper to recompute the value (i.e. to remat it), rather than to store and
reload it. 
An example of this can be
o Calculate Frame Pointer(FP) + offset ->store to say r150
o Spill/restore r150 to/from stack even though it would be cheaper to 
  clobber r150 and regenerate it from scratch.
 
Remat can score over spilling (in terms of aggregate cost of remat/spill
instructions generated) in a number of cases such as frame pointer/static
data calculation related spills and also other trivial calculations from
ever live values in a function.

The new register allocator seem to remat only constant loads. I plan to
enhance the remat infrastructure  as follows -
  
o  Collect remat information during the data flow pass itself (to propagate
live range information)  - (in df.c) 
o The remat v/s spill cost criteria can't be directly applied in the current
framework (as no hard stack slots are assigned during spilling, so can't
determine the spill cost). A workaround for remat/spill criteria might be to
find sure shot cases of better remat/spill and take spill decision
accordingly.
 
Example of such a case (sure remat case) could be spilling of a def before
its first use. Here, spill can be avoided by moving the def being spilled
closer to its use. Other such cases can be reasoned out and treated
likewise.

Thoughts and comments awaited.
 
Best Regards,
Mukta