Re: [new-regalloc-branch] delayed rematerialization

[Denis Chertykov <denisc at overta dot ru>]

Michael Matz <matz@suse.de> writes:

> Hi Denis,
> 
> On Sun, 19 Jan 2003, Denis Chertykov wrote:
> 
> > The following patch consists of few parts:
> > 1. Bug fixing. We can't coalesce web1 and web2
> >    if web1->add_hardregs != 0 and intersected usable_regs havn't block of
> >    required length;
> 
> This makes sense, yes.
> 
> > 2. Allow rematerialization of function arguments passed in stack.
> >    I have used REG_EQUIV note for detecting rematerializable arguments;
> 
> Hmm, I see that I have not commited my version for some months ;-|  I've
> done something similar, but I not only remat function args (you
> explicitely check for containing the arg pointer), but simply everything
> in the REG_EQUIV note, if I encounter one.  Something like this:
> 
> +              || ((note = find_reg_note (insn, REG_EQUIV, NULL_RTX))
> +                  && rtx_equal_p (XEXP (note, 0), src)
> +                  && !contains_pseudo (src)))
> 
> (at the same place where you added the call to
> rematerializable_stack_arg_p() ).

May be your right, but I don't know how to do with the following
insns.

Port - rs6000
C example: `int i (double d) { return d; }'

Fragment of ppc.c.23.lreg (gcc with -fno-new-ra):

(insn 26 3 27 0 (nil) (set (reg:DI 121)
        (unspec:DI [
                (fix:SI (reg/v:DF 119))
            ] 10)) 209 {fctiwz} (insn_list 3 (nil))
    (expr_list:REG_EQUIV (mem/f:DI (plus:SI (reg/f:SI 31 r31)
#              ^^^^^^^^^  Seems strange for me :-\
                (const_int 8 [0x8])) [4 S8 A64])
        (expr_list:REG_DEAD (reg/v:DF 119)
            (nil))))

(insn 27 26 18 0 (nil) (set (mem/f:DI (plus:SI (reg/f:SI 31 r31)
                (const_int 8 [0x8])) [4 S8 A64])
        (reg:DI 121)) 329 {*movdi_internal32} (insn_list 26 (nil))
    (expr_list:REG_DEAD (reg:DI 121)
        (nil)))
--------------------------------------------------------------------

I have removed insns with REG_EQUIV after rematerialization was done.
In the case above I can't do that. So, I used only stack passed
arguments.

> 
> > 3. Delayed rematerialization. Main idea of this part is not
> >    substitute web uses to web->pattern in emit_loads. Try to spill web
> >    and substitute web uses to web->pattern only if spilled web isn't
> >    got color (colored by an_unusable_color).
> 
> I'm still catching up with your former changes to emitting the spill code
> (it now looks quite a bit different than I remember ;-) ).
> The current patch here ...

Just to clarify: "delayed rematerialization" and these changes are
different things. (May be a bit interfered).

> 
> > *************** emit_loads (ri, nl_first_reload, last_bl
> > *** 1104,1110 ****
> >   	slot = simplify_gen_subreg (GET_MODE (reg), slot, innermode,
> >   				    SUBREG_BYTE (reg));
> >         if (web->one_load && web->last_use_insn
> > ! 	  && (GET_CODE (slot) == MEM || supweb->pattern)
> >   	  && ra_validate_change (web->last_use_insn,
> >   				 DF_REF_LOC (web->last_use), slot, 0))
> >   	{
> > --- 1093,1099 ----
> >   	slot = simplify_gen_subreg (GET_MODE (reg), slot, innermode,
> >   				    SUBREG_BYTE (reg));
> >         if (web->one_load && web->last_use_insn
> > !  	  && copy_insn_p (web->last_use_insn, NULL,NULL)
> >   	  && ra_validate_change (web->last_use_insn,
> >   				 DF_REF_LOC (web->last_use), slot, 0))
> 
> ... for instance now changes last_use_insn only if it was a copy, which
> means, that we potentially emit more insns than before.  Together with the
> fact that most often stack-pseudos aren't coalesced (or are they now?) we
> get more register pressure.  Why is the above necessary?

About constraining class for the spill slot register:
 insn1 use p100 (p100 - GENERAL_REGS)
 ....
 ....
 insn2 use p100 (p100 - GENERAL_REGS)
 insn3 use p100 (p100 - CREG)
We spill p100.
If you will insert a move (with spill pseudo) between insn2 and insn3
you will have relaxed spill pseudo. If you incorporate spill pseudo
into insn3 you will have an "over-constrained" spill pseudo.

> All in all, I think the parts 1) and 2) of this patch are undisputable
> (maybe with my broadening of allowing all REG_EQUIVs), but I'm unsure
> about 3).  Have you more patches to commit in the near term (say a
> week)?

No.

But, I want to discuss my committed patch and part 3) of current
patch. Are you OK ? (I want to send you examples.)


Denis.