This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [new-ra] "#if DENIS"


Michael Matz <matz@suse.de> writes:

> Hi,
> 
> On 10 Jul 2003, Denis Chertykov wrote:
> 
> > IMHO: ix86 also has a significant restrictions. Has a very small classes.
> 
> Yes, but this situation doesn't depend on the size of the class itself,
> but how restricted the different pseudo are compared to their maximum
> class (e.g. GENERAL_REGS).  _This_ influences if stack pseudos are
> possibly colored in the next pass, or not.
> 
> > > p86 is not colored.
> >
> > No.
> > Current allocator generate slack slots only in one place.
> > It's assign_stack_slots_1:2527
> 
> Yes, I completely forgot about this situation, i.e. that you changed the
> allocator to also allocate stack pseudos for spilled rematerializable webs
> (in fact for all webs) in order to implement assign_stack_slots_1.  Sorry
> about that.  This is also the reason why the allocator currently emits the
> code it does emit on the testcase, if we don't add your spilling method
> again.
> 
> I will try to sort out the complicateness here.  Basically I want to merge
> the old method, i.e. rematerialized spilled webs don't get a stack pseudo,
> with the current one.  The old method will be used, _except_ when they
> were spilled because of too narrow class (or some other heuristic).  Then
> they are spilled to normal new pseudos (not stack pseudos), which then
> have the possibility to become colored next round.  This would reflect
> what you want from them, I believe.

Generally yes. Main idea of delayed remat. was: try to colorize
spilled web before real spilling(remat.). All additional moves
generated by spilling process will be removed by coalesce_spill_slot
if spilling was unlucky.
Really I'm prefer splitting here not a spilling.
(Too similar spelling of different things spilling and splitting.)

> 
> Basically it would go like this:
>   web X is spilled
>     1) it's spilled because unfortunate limited class compared to the
>        widest possible useful class
>        --> spill them to normal new pseudos, which then get that wider
>            class.  I'm not sure how to call such pseudos.  Hmm, backing
>            pseudos maybe.  (We need to differentiate them from stack
>            pseudos and from normal pseudos, I think).

As I understand you in this phase you will use splitting not a
spilling. Is this right ?
And new pseudos can be called as split pseudos.

>     2) otherwise (spilled because really too high pressure)
>        two cases:
>        a) it's rematerializable
>           --> emits loads of the rematerializable expression
>        b) it's not remat
>           --> spill it to stack pseudos
> 
> Additionally on architectures with limited addressing modi we have to
> allocate real stack slots for all stack pseudos, or backing pseudos which
> didn't get a color (i.e. an_unusable_color).  Currently this is done
> unconditionally.

I'm agree with you.
Are you sure that all stack slots which being incorporated to insns
will be accepted by constraints checking ? (even on ix86)
I'm not. Reload will be required.
In this case I'm prefer to have an additional pass of allocation than
pass of reload.

IE:
  if (/* !spill_p && */ subst_to_stack_p ())
    /* If you uncomment the SPILL_P usage then you will have a calls to
       assign_stack_slots only at end of allocation process.
       See to the caller of actual_spill.  */

IMHO: Better to have the one call to assign_stack_slots and may be
one or two (no more than two, I believe) passes of allocation than one
reload pass.
It's my strong opinion. Are you think that I'm wrong ? or you have a
different opinion ?

Also, I can't understand why you use validate_change not ra_validate_change.
As I understand: you want to incorporate spill pseudo to insn, but
this spill pseudo can be colored (again my view:). Is this right ?
IMHO: It's right. You want to have a chance to colorize all such pseudos to
      the end of allocation. It's right. (Also, better stack allocation)
But, I can't understand why you don't want to be sure that insn
modified right. Only ra_validate_change can check this. You not use
pre-reload pass on such insns and webclass for web with spill pseudo
will be wrong.

In my (#if DENIS) cases of similar conditions I have used copy_insn_p
to disable overconstraining a new spill pseudo (I hope that src or
dest of move can work with any class). But now allocator will have a
separate split pass (it's 1) in your model above) and you can try to
keep all insns correct. And try to remove reload at all.

Possibly I miss something. What ?

> 
> Does the above sound sensible so far?  This should also reduce the
> required number of rounds again a bit.  Currently because even remat webs
> are first spilled to pseudos instead of directly spilled as expressions,
> it means that sometimes an additional round of spilling is
> introduced.

I'm agree I have increased number of passes. It's not a good.

Denis.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]