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

[Ian Lance Taylor <iant at google dot com>]

Paolo Bonzini <bonzini@gnu.org> writes:

> > 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.
> 
> I don't really think so.  For MIPS, it is going to favor registers
> whose preferred class is MD*_REG, over those whose preferred class is
> LO_AND_GR_REGS.
> 
> But on MIPS in particular, I doubt regclass will give a preferred
> register class of MD*_REG to anything, because moves from and to LO/HI
> use starred constraints to avoid this case.  My regalloc-fu is low,
> but IIUC this means that only reload can create moves from/to the
> multiplication result registers.

The point is that in general even machines with large numbers of
registers have classes with few registers.  Your proposal may
significantly change the register allocator's behaviour on those
machines.  It may be fine.  It may not.  I don't know.  Can you
convince me?

> 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.


> > What happens if you only use size of register class as a tie-breaker
> > for quantities which are otherwise equal?
> 
> I'm worried that in general it won't work, because priorities are
> rarely exactly equal (mostly because of the live range).  I'm almost
> sure this happens for the PR testcase, but I don't have data at hand.

Let's find out.


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.  Experience
suggests that other test cases will get worse.  I don't know which
effect will dominate.

Ian