Move insn out of the way

[Paulo J. Matos]

On 10/08/11 12:40, Richard Guenther wrote:
>
> On x86 we expand the code to ((xl&  al) ^ al) | ((xh&  ah) ^ ah) == 0
> which is then if-converted.  Modified testcase:
>
> long long x;
> _Bool __attribute__((regparm(2))) mask (long long a)
> {
>    return (x&  a) == a;
> }
>
> on i?86 gets you
>
> mask:
> .LFB0:
>          .cfi_startproc
>          pushl   %ebx
>          .cfi_def_cfa_offset 8
>          .cfi_offset 3, -8
>          movl    %eax, %ebx
>          andl    x, %ebx
>          movl    %edx, %ecx
>          andl    x+4, %ecx
>          xorl    %ebx, %eax
>          xorl    %ecx, %edx
>          orl     %edx, %eax
>          sete    %al
>          popl    %ebx
>          .cfi_restore 3
>          .cfi_def_cfa_offset 4
>          ret
>
> so I wonder if you should investigate why the xor variant doesn't trigger
> for you?

I can reproduce this result in GCC 4.6.1 for x86.
I can't understand what you mean by this though. From inspecting the 
logs it seems that the if-conversion is done manually at expand time. 
The final pass before expand shows the original (x & a) == a, however, 
after expand the rtl already contains xor, ior, etc. So I guess I would 
need to do something similar in my backend. I can't however, find in the 
i386(.md|.c) where this is actually happening.

> On i?86 if-conversion probably solves your specific issue,
> but I guess the initial expansion is where you could improve placement
> of the 1 (after all, the 0 is after the jumps).
>

This is happening on my own backend so I guess anything that is 
implemented to do if-conversion on i386 needs to be implemented also on 
my backend. Can you point me to the code on i386 so I can take a look at it?

Cheers,

-- 
PMatos