Re: PING: PR/17236, improve long long multiply on x86 (middle-end)

[Ian Lance Taylor <iant@google.com>]

Paolo Bonzini <bonzini@gnu.org> writes:

> http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00995.html
> 
> 2007-12-20  Paolo Bonzini  <bonzini@gnu.org>
> 
> 	* combine.c (simplify_set): Try to canonicalize SETS with
> 	swap_commutative_operands_with_target.
> 	* optabs.c (swap_commutative_operands_with_target): Move...
> 	* rtlanal.c (swap_commutative_operands_with_target): ... here.
> 	* rtl.h (swap_commutative_operands_with_target): Add prototype.

This part of the patch is OK.


> 	* regclass.c (record_reg_classes): Favor the class of the destination
> 	operand if the source dies in this instruction.

I don't see anything here which prevent pp->cost[classes[j]] from
going negative.  This patch is OK if you add a check that the value is
greater than zero before you decrement it.


> 	* local-alloc.c (QTY_CMP_PRI): Bump priority of registers with a
> 	small suggested class.

You need to update the comments.  And if you read the comments, you
will see that the current formula is also used in global.c, in
allocno_compare.  Actually the two formulas are very close but not
quite identical; for some reason they differ in how they handle the
size of the pseudo.

This change is going to give a big bump to registers whose preferred
class has only one or two registers, such as the HI/LO registers on
MIPS.  It's hard to know whether the effect will be beneficial.

What happens if you only use size of register class as a tie-breaker
for quantities which are otherwise equal?

In general I can see the advantage to allocating registers in smaller
register classes first, especially when there is an overlap between
classes.  But I'm not yet convinced that this is the best way to do
so.

Thanks.

Ian