This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [new-ra] "#if DENIS"
- From: Denis Chertykov <denisc at overta dot ru>
- To: Michael Matz <matz at suse dot de>
- Cc: Denis Chertykov <denisc at overta dot ru>, gcc-patches at gcc dot gnu dot org
- Date: 10 Jul 2003 23:55:31 +0400
- Subject: Re: [new-ra] "#if DENIS"
- References: <Pine.LNX.4.44.0307101934370.12656-100000@wotan.suse.de>
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.