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

[Paolo Bonzini <bonzini at gnu dot org>]

> > That said, I wonder if it might actually make sense (no, I didn't
> > think it that way, but I ask) if we do this change only in
> > local-alloc.c?
>
> I think you need to make an argument for why that would be better.

Because local-alloc.c only allocates registers with a relatively short 
live range, and bumping the priority of smaller register classes would 
be less disrupting.

> I'm OK with making this sort of change without a clear argument, but
> only if you're prepared to do performance testing on three or more
> primary platforms.  I'm not OK with making this sort of change with
> neither an argument nor performance testing.  Right now, as far as I
> know, you just have a single test case which improves.

I already had SPEC on x86 and it was neutral, except that half of SPECfp 
was perturbated by the machine load.  I should be able to rerun it 
sometime next week.  Running i386 and x86_64 would not be very different 
(the RA problems are the same -- %eax/%edx for MUL/DIV and %cl for shift 
counts) and I don't have access to other platforms.

So, I will try to audit other back-ends like I did for MIPS.  Before 
that, I will see what IRA does; maybe we don't need at all the patch.

Paolo