This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Dumb register allocation (PPC)
- From: law at redhat dot com
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 12 May 2002 16:36:24 -0600
- Subject: Re: Dumb register allocation (PPC)
- Reply-to: law at redhat dot com
In message <20020512193645.GA374@codesourcery.com>, Zack Weinberg writes:
> I noticed this while I was looking at something else. This function
>
> static hashval_t
> const_double_htab_hash (x)
> const void *x;
> {
> hashval_t h = 0;
> size_t i;
> rtx value = (rtx) x;
>
> for (i = 0; i < sizeof(CONST_DOUBLE_FORMAT)-1; i++)
> h ^= XWINT (value, i);
> return h;
> }
>
> gets compiled like this on PowerPC (-mregnames for clarity):
>
> const_double_htab_hash:
> li %r4, 3
> li %r9, 0
> mtctr %r4
> addi %r3, %r3, 12
> .L13:
> lwz %r4, 0(%r3)
> addi %r3, %r3, 8
> xor %r9, %r9, %r4
> bdnz .L13
> mr %r3, %r9
> blr
>
> Unless there is something weird about the architecture which I'm not
> aware of, it appears that we could get rid of the final move
> instruction by swapping %r9 and %r3. %r3 holds the input parameter
> but we've got three-operand add so that's not a difficulty.
>
> const_double_htab_hash:
> li %r4, 3
> addi %r9, %r3, 12
> mtctr %r4
> li %r3, 0
> .L13:
> lwz %r4, 0(%r9)
> addi %r9, %r9, 8
> xor %r3, %r3, %r4
> bdnz .L13
> blr
>
> So why don't we do that automatically? Presumably this is register
> allocation's fault...
Start looking at the dumps. Of particular interest will be the incoming
hard register, the outgoing hard register and any pseudos in between.
You'd start the process by looking to see if they conflict with each other.
jeff