Make SPEC2000 and the new allocator

Make SPEC2000 and the new allocator

[Michael Matz]

Hi,

this fixes a misunderstanding on my side, where the allocator on
x86 sometimes assignes registers from MMX_REGS to the stack pseudos.
Until webclass is real we need to constrain ourself to GENERAL_REGS here,
so:

OK?

Ciao,
Michael.
-- 
	* ra-build.c (remember_web_was_spilled): Use GENERAL_REGS.

Index: ra-build.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/ra-build.c,v
retrieving revision 1.3
diff -u -p -r1.3 ra-build.c
--- ra-build.c	16 Jul 2002 11:29:14 -0000	1.3
+++ ra-build.c	18 Jul 2002 16:23:24 -0000
@@ -2349,7 +2349,8 @@ remember_web_was_spilled (web)
 			reg_class_contents[reg_alternate_class (web->regno)]);
     }
   else
-    COPY_HARD_REG_SET (web->usable_regs, reg_class_contents[(int) ALL_REGS]);
+    COPY_HARD_REG_SET (web->usable_regs,
+		       reg_class_contents[(int) GENERAL_REGS]);
   AND_COMPL_HARD_REG_SET (web->usable_regs, never_use_colors);
   prune_hardregs_for_mode (&web->usable_regs, PSEUDO_REGNO_MODE (web->regno));
 #ifdef CLASS_CANNOT_CHANGE_MODE

Re: Make SPEC2000 and the new allocator

[Daniel Berlin]

On Thursday, July 18, 2002, at 12:28  PM, Michael Matz wrote:

> Hi,
>
> this fixes a misunderstanding on my side, where the allocator on
> x86 sometimes assignes registers from MMX_REGS to the stack pseudos.
Err, so?

Intel's compiler does the same thing.

> Until webclass is real we need to constrain ourself to GENERAL_REGS 
> here,
> so:
>
> OK?
>

Bad idea, won't this will possibly screw performance on other 
architectures who don't have this problem?  Or is GENERAL_REGS supposed 
to contain all the regs we'd ever want to use as spill regs? (I can 
never remember the class names->use mapping)
If not, why don't we just add a new register class on all architectures 
labeled "SPILL_REGS" or something, so we can know *exactly* what 
registers we might be allowed to use for spills (in case we ever run 
into some architecture with extra-funky restrictions or something).

> Ciao,
> Michael.
> -- 
> 	* ra-build.c (remember_web_was_spilled): Use GENERAL_REGS.
>
> Index: ra-build.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/ra-build.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 ra-build.c
> --- ra-build.c	16 Jul 2002 11:29:14 -0000	1.3
> +++ ra-build.c	18 Jul 2002 16:23:24 -0000
> @@ -2349,7 +2349,8 @@ remember_web_was_spilled (web)
>  			reg_class_contents[reg_alternate_class (web->regno)]);
>      }
>    else
> -    COPY_HARD_REG_SET (web->usable_regs, reg_class_contents[(int) 
> ALL_REGS]);
> +    COPY_HARD_REG_SET (web->usable_regs,
> +		       reg_class_contents[(int) GENERAL_REGS]);
>    AND_COMPL_HARD_REG_SET (web->usable_regs, never_use_colors);
>    prune_hardregs_for_mode (&web->usable_regs, PSEUDO_REGNO_MODE 
> (web->regno));
>  #ifdef CLASS_CANNOT_CHANGE_MODE
>
>

Re: Make SPEC2000 and the new allocator

[Jan Hubicka]

> 
> On Thursday, July 18, 2002, at 12:28  PM, Michael Matz wrote:
> 
> >Hi,
> >
> >this fixes a misunderstanding on my side, where the allocator on
> >x86 sometimes assignes registers from MMX_REGS to the stack pseudos.
> Err, so?
> 
> Intel's compiler does the same thing.

You can't do that on pre P4 machines as you need femms.
> >-    COPY_HARD_REG_SET (web->usable_regs, reg_class_contents[(int) 
> >ALL_REGS]);
> >+    COPY_HARD_REG_SET (web->usable_regs,
> >+		       reg_class_contents[(int) GENERAL_REGS]);

I believe you want:
/* Find the largest class for which every register number plus N is
   valid in M1 (if in range) and is cheap to move into REGNO.
   Abort if no such class exists.  */

static enum reg_class
find_valid_class (m1, n, dest_regno)

With dest_regno replaced by dest_class (the function don't use regno
anyway)

Honza
> >   AND_COMPL_HARD_REG_SET (web->usable_regs, never_use_colors);
> >   prune_hardregs_for_mode (&web->usable_regs, PSEUDO_REGNO_MODE 
> >(web->regno));
> > #ifdef CLASS_CANNOT_CHANGE_MODE
> >
> >

Re: Make SPEC2000 and the new allocator

[Daniel Berlin]

On Thu, 18 Jul 2002, Jan Hubicka wrote:

> > 
> > On Thursday, July 18, 2002, at 12:28  PM, Michael Matz wrote:
> > 
> > >Hi,
> > >
> > >this fixes a misunderstanding on my side, where the allocator on
> > >x86 sometimes assignes registers from MMX_REGS to the stack pseudos.
> > Err, so?
> > 
> > Intel's compiler does the same thing.
> 
> You can't do that on pre P4 machines as you need femms.

Ahh.
At least, however, you should be able to spill to the xmm registers 
without femms, no?
--Dan

Re: Make SPEC2000 and the new allocator

[Jan Hubicka]

> On Thu, 18 Jul 2002, Jan Hubicka wrote:
> 
> > > 
> > > On Thursday, July 18, 2002, at 12:28  PM, Michael Matz wrote:
> > > 
> > > >Hi,
> > > >
> > > >this fixes a misunderstanding on my side, where the allocator on
> > > >x86 sometimes assignes registers from MMX_REGS to the stack pseudos.
> > > Err, so?
> > > 
> > > Intel's compiler does the same thing.
> > 
> > You can't do that on pre P4 machines as you need femms.
> 
> Ahh.
> At least, however, you should be able to spill to the xmm registers 
> without femms, no?
Yes, but the integer->xmm move is expensive.  You should at least
consult register move cost whether it is cheaper than memory spill.  For
Athlon reg->xmm move is more expensive than int->mem->xmm move and even
for P3/4 I believe int->xmm->int is more expensive than int->mem->int

If I understand it properly the spill registers are supposed to be
spilled by reload, so why to worry at first place?

Honza
> --Dan

Re: Make SPEC2000 and the new allocator

[Daniel Berlin]

On Thu, 18 Jul 2002, Jan Hubicka wrote:

> > On Thu, 18 Jul 2002, Jan Hubicka wrote:
> > 
> > > > 
> > > > On Thursday, July 18, 2002, at 12:28  PM, Michael Matz wrote:
> > > > 
> > > > >Hi,
> > > > >
> > > > >this fixes a misunderstanding on my side, where the allocator on
> > > > >x86 sometimes assignes registers from MMX_REGS to the stack pseudos.
> > > > Err, so?
> > > > 
> > > > Intel's compiler does the same thing.
> > > 
> > > You can't do that on pre P4 machines as you need femms.
> > 
> > Ahh.
> > At least, however, you should be able to spill to the xmm registers 
> > without femms, no?
> Yes, but the integer->xmm move is expensive.  You should at least
> consult register move cost whether it is cheaper than memory spill.  For
> Athlon reg->xmm move is more expensive than int->mem->xmm move and even
> for P3/4 I believe int->xmm->int is more expensive than int->mem->int
> 
> If I understand it properly the spill registers are supposed to be
> spilled by reload, so why to worry at first place?

No, we insert spill code, not reload.

> 
> Honza
> > --Dan
> 
> 

Re: Make SPEC2000 and the new allocator

[Jan Hubicka]

> > > Ahh.
> > > At least, however, you should be able to spill to the xmm registers 
> > > without femms, no?
> > Yes, but the integer->xmm move is expensive.  You should at least
> > consult register move cost whether it is cheaper than memory spill.  For
> > Athlon reg->xmm move is more expensive than int->mem->xmm move and even
> > for P3/4 I believe int->xmm->int is more expensive than int->mem->int
> > 
> > If I understand it properly the spill registers are supposed to be
> > spilled by reload, so why to worry at first place?
> 
> No, we insert spill code, not reload.

OK, then I guess you can compute the primary register class based on
REGISTER_MOVE_COST as largest class the register is cheapest to move into
(this is done in the reload function I quoted) and alternate class as a
largest class register is cheaper to move into than move into memory...

Honza
> 
> > 
> > Honza
> > > --Dan
> > 
> > 

Re: Make SPEC2000 and the new allocator

[Michael Matz]

Hi,

On Thu, 18 Jul 2002, Daniel Berlin wrote:

> > [... not using mmx regs for stack pseudo, idea to use xmm regs ...]
>
> No, we insert spill code, not reload.

Yes, but it's all not that big an issue.  The registers which are now only
based on GENERAL_REGS are the ones I call stack pseudos.  This doesn't
apply to normal spill temporaries.

The stack pseudos really stand for stackslots, i.e. they were produced in
a former pass of allocation instead of a stack slot to hold the value of a
spilled web.  The reason I do not use stack slots is, that I can better
track the lifetime of this thing, when it's a pseudo.  So it later has the
chance (due to other webs also spilled) to become colorable again, so in
the end maybe no stackslot is needed.  But that's a pure optimization
already.  If such stack pseudo doesn't get a color, it will be literally
replaced by a stack slot.  This also means that these stack pseudos are
not spilled again, if they don't get a color.  Basically they are handled
like colorable stackslots, which can be replaced back by registers.

Using a reg class and narrowing it down based on the mode is anyway just
an intermediate solution until we have really constraint based register
set choosing for webs.


Ciao,
Michael.

Re: Make SPEC2000 and the new allocator

[Daniel Berlin]

On Friday, July 19, 2002, at 04:27  AM, Michael Matz wrote:

> Hi,
>
> On Thu, 18 Jul 2002, Daniel Berlin wrote:
>
>>> [... not using mmx regs for stack pseudo, idea to use xmm regs ...]
>>
>> No, we insert spill code, not reload.
>
> Yes, but it's all not that big an issue.  The registers which are now 
> only
> based on GENERAL_REGS are the ones I call stack pseudos.  This doesn't
> apply to normal spill temporaries.

Gotcha.  Wasn't paying much attention to the context of the patch (3 
lines didn't help. :P).

I had a recollection we tried to come up with exact colors (or at 
least, had code that didn't just make them ALL_REGS or GENERAL_REGS) 
for spill webs in the next pass, but I wasn't sure I was remembering 
the code right.

I'll go back to sleep till we have some fast way of determining the 
actual register set we could put a pseudo in (ie constraint based).


> Ciao,
> Michael.
>
>

Re: Make SPEC2000 and the new allocator

[Michael Matz]

Hi,

On Fri, 19 Jul 2002, Daniel Berlin wrote:

> Gotcha.  Wasn't paying much attention to the context of the patch (3
> lines didn't help. :P).

Hmm, for me they were also not enough it seems, or I'm becoming senile.  I
actually got my explanation exactly backwards.  I.e. stack pseudos get the
correct class (based on regclass), but spill temps were based on the
narrowed ALL_REGS (and now GENERAL_REGS), so your comment was entirely
correct.  There is no good solution besides implementing webclass.
Alternatively implementing Honzas idea could also be enough for the time
being.  But for now I leave it as it is, so as to not produce wrong code
at least.


Ciao,
Michael.