RE: Register Rematerialization In New Register Allocator

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

Thanks for the information.

As I understand from the thread and also the description of patch in

http://gcc.gnu.org/ml/gcc-patches/2003-01/msg01323.html

delayed remat seems fine, but the _scope_ of values being remat seems to be
limited to stack loads and additionally function arguments passed on stack.
But we could enhance remat to take care of other possibilities like frame
pointer related calculations, static data area related calculations and
other such values which are ever live(never killed) within a function and
technically can be called as remat. To cite a comment in the source code

			/* XXX Currently we can't use patterns which contain
                  pseudos, _even_ if they are stable.  The code simply isn't
                  prepared for that.  All those operands can't be spilled
(or
                  the dependent remat webs are not remat anymore), so they
                  would be oldwebs in the next iteration.  But currently
                  oldwebs can't have their references changed.  The
                  incremental machinery barfs on that.  */

			Condition Check for this:
			|| (!rtx_unstable_p (src) && !contains_pseudo (src))

This is the particular area which I intend to incorporate i.e. pseudo
handling in case of remat.
More comments welcome..

Mukta


>"Mukta Punjani, Noida" <muktap@noida.hcltech.com> writes:
>
>> 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.



>
>Few months ago I have a long discussion with Michael Matz about
>rematerialization and related problems.
>Discussion (mail by mail, <Gazovik it's me>):
>
>From: Gazovik <gazovik@overta.ru>
>Subject: Example of delayed remat
>To: matz@suse.de
>CC: denisc@overta.ru
>Date: Wed, 22 Jan 2003 17:08:04 +0300
>Reply-To: Gazovik <gazovik@overta.ru>
>Organization: Gazovik
>
>Hi Michael !
>
>This is an example of delayed rematerialization.
...


>From: Gazovik <gazovik@overta.ru>
>Subject: Example of delayed remat
>To: matz@suse.de
>CC: denisc@overta.ru
>Date: Thu, 23 Jan 2003 16:32:35 +0300
>Reply-To: Gazovik <gazovik@overta.ru>
>Organization: Gazovik
>
>Hi Michael !
>
>I will try to rearrange my thoughts about delayed remat.
>
>Abstract:
>1. Originally new allocator has only IR spilling;
>2. After that you have added web splitting based on IR 
>spilling. I wrote about
>   generation spill pseudos instead of stack slots. I call it 
>IR splitting.
>
>So, now we play with allocator with IR splitting + IR spilling.
>OK ?
>
>The allocation process (simplified):
>1. Try to colorize webs;
>2. Choose webs for spilling; (Webs selection based on coloring 
>algorithm
>                              not on web cost, but on web degree.
>                              It's symplify not select_spill.)
>3. Choose webs with lowest cost for spilling; (It's select_spill)
>4. Recolor spills;
>5. Actual spilling or stack slots allocation.
>   Actual spilling is an IR splitting not a spilling.
>   Stack slots allocation is an IR spilling on top of IR splitting.
>   Stack slots allocation is assign_stack_slots ().
>
...