This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Move insn out of the way
On Thu, Aug 11, 2011 at 10:11 AM, Paulo J. Matos <paulo@matos-sorge.com> wrote:
> On Thu, Aug 11, 2011 at 1:01 AM, Vladimir Makarov <vmakarov@redhat.com> wrote:
>> I can not reproduce the problem.? It would be nice to give all info (the
>> code without includes and all options).? In this case I could have more info
>> to say more definitely about the reason of the problem in IRA.
>>
>
> One of the issue with these problems of mine is that they are tied to
> my backend, but not always. I think I managed to reproduce a similar
> result in the avr backend using GCC4.6.1
>
> test.c:
> long long x;
> _Bool mask (long long a)
> {
> ?return (x & a) == a;
> }
>
> $ avr-cc1 -Os test.c
>
> This generates the following assembler:
> mask:
> ? ? ? ?push r13
> ? ? ? ?push r14
> ? ? ? ?push r15
> ? ? ? ?push r16
> ? ? ? ?push r17
> /* prologue: function */
> /* frame size = 0 */
> /* stack size = 5 */
> .L__stack_usage = 5
> ? ? ? ?lds r14,x
> ? ? ? ?and r14,r18
> ? ? ? ?lds r15,x+1
> ? ? ? ?and r15,r19
> ? ? ? ?lds r16,x+2
> ? ? ? ?and r16,r20
> ? ? ? ?lds r17,x+3
> ? ? ? ?and r17,r21
> ? ? ? ?lds r27,x+4
> ? ? ? ?and r27,r22
> ? ? ? ?lds r26,x+5
> ? ? ? ?and r26,r23
> ? ? ? ?lds r31,x+6
> ? ? ? ?and r31,r24
> ? ? ? ?lds r30,x+7
> ? ? ? ?and r30,r25
> ? ? ? ?clr r13
> ? ? ? ?inc r13
> ? ? ? ?cp r14,r18
> ? ? ? ?brne .L3
> ? ? ? ?cp r15,r19
> ? ? ? ?brne .L3
> ? ? ? ?cp r16,r20
> ? ? ? ?brne .L3
> ? ? ? ?cp r17,r21
> ? ? ? ?brne .L3
> ? ? ? ?cp r27,r22
> ? ? ? ?brne .L3
> ? ? ? ?cp r26,r23
> ? ? ? ?brne .L3
> ? ? ? ?cp r31,r24
> ? ? ? ?brne .L3
> ? ? ? ?cpse r30,r25
> .L3:
> ? ? ? ?clr r13
> .L2:
> ? ? ? ?mov r24,r13
> /* epilogue start */
> ? ? ? ?pop r17
> ? ? ? ?pop r16
> ? ? ? ?pop r15
> ? ? ? ?pop r14
> ? ? ? ?pop r13
> ? ? ? ?ret
> ? ? ? ?.size ? mask, .-mask
> ? ? ? ?.comm x,8,1
>
>
> I can't tell how good or bad this assembler is but I note a couple of
> similarities with my backends assembler output:
> - It doesn't do if-conversion like Richard suggested. So (x & a) == a
> is not converted to ((xl & al) ^ al) | ((xh & ah) ^ ah) == 0.
> - The assignment of r13 to 1 is done as 'clr r13; inc r13' _before_ the jumps.
>
> The only assignment to r13 is as in my case after the jumps as 'clr
> 13' to set up the return value. I am not sure if this situation causes
> a lot of register pressure, however I think it doesn't in avr but it
> does in my backend. AVR has 32 registers to play with, mine can only
> deal with 3 in the destination operand position.
What I was expecting IRA to do is
1) split live-range at kills, thus if a constant is assigned to a pseudo
then the constant has its own live-range
2) pseudos that are equal to a constant are assigned hard registers
last if re-materializing them during reload is cheaper than spilling them
I suspect that 1) is not happening, I hope that 2) would happen already.
Correct?
Richard.
> --
> PMatos
>