This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR middle-end/28690, indexed load/store performance + reload bug
On Wed, 2007-01-10 at 08:17 +0100, Paolo Bonzini wrote:
> Yes, mostly (see comments down in the patch). Unless somebody knows why
> x86 prefers set X X Y, however, I can only point you to the testcase.
> :-( I'm CCing Jan.
I think I've lost track of the testcase...unless you mean the entire
crafty benchmark. Can you point me to it again. If it's a standalone
testcase, I might be able to find an x86 box to test on myself.
> Actually, I meant
>
> if (REG_P (op))
> return REG_POINTER (op) ? -1 : -2;
> else
> return -3;
Which is how I originally coded it up. However, coding it that way
caused me to miss an opportunity to transform one of the indexed load
test cases. We ended up with the following two ops being passed to
swap_commutative_operands_p (x,y) and swapping them because the REG
had a higher precedence than the MEM.
x = (mem/f:SI (plus:SI (reg/v/f:SI 159 [ base ])
(reg:SI 164)) [2 S4 A32])
y = (reg:SI 154 [ pretmp.32 ])
How do we catch this case? Maybe order them like:
/* REG_POINTER, MEM_POINTER, REG, MEM */
if (REG_P (op))
return REG_POINTER (op) ? -1 : -3;
else
return (MEM_P (op) && MEM_POINTER (op)) ? -2 : -4;
Of course changing the other values so we don't overlap with the other
values. Any other way to catch this case you can think of?
> And then swap_commutative_operands_with_target could die entirely.
How so, since the change to commutative_operand_precedence doesn't
account for the preference of wanting set X X Y over set X Y X?
Peter