On Thu, 2013-02-28 at 18:12 +, Richard Sandiford wrote:
> > I'll try your patch on some of my benchmarks and see what happens.
>
> Thanks.
When I removed mips_order_regs_for_local_alloc I didn't see any
differences, when I changed the ordering of REG_ALLOC_ORDER I saw
a savings of a few byte
Steve Ellcey writes:
> On Wed, 2013-02-27 at 22:28 +, Richard Sandiford wrote:
>> FWIW, after seeing that, I tried the patch below. Disabling
>> ADJUST_REG_ALLOC_ORDER seemed to be a very mixed bag sizewise though --
>> certainly not the consistent win that I hoped -- and I wasn't set up to
>
On Wed, 2013-02-27 at 22:28 +, Richard Sandiford wrote:
> FWIW, after seeing that, I tried the patch below. Disabling
> ADJUST_REG_ALLOC_ORDER seemed to be a very mixed bag sizewise though --
> certainly not the consistent win that I hoped -- and I wasn't set up to
> do proper speed testing.
"Steve Ellcey " writes:
> I was looking at MIPS register allocation and I noticed an odd thing.
> There is a definition of REG_ALLOC_ORDER in mips.h but in
> mips_order_regs_for_local_alloc (mips.c), we do not use this ordering,
> we just have:
>
> for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
>
I was looking at MIPS register allocation and I noticed an odd thing.
There is a definition of REG_ALLOC_ORDER in mips.h but in
mips_order_regs_for_local_alloc (mips.c), we do not use this ordering,
we just have:
for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
reg_alloc_order[i] = i;
I was wo
