llvm dev - Sep 2010 - [LLVMdev] comparison pattern trouble

Our architecture has 1-bit boolean predicate registers.

I've defined comparison


def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2),
"", [(set I1Regs:$op3, (setne I32Regs:$op1, I32Regs:$op2))]>;




But then I end up having the following bug:


Code


  %0 = zext i8 %data to i32
  %1 = zext i16 %crc to i32
  %2 = xor i32 %1, %0
  %3 = and i32 %2, 1
  %4 = icmp eq i32 %3, 0


which compares the lowest bits of the 2 variables


ends up being compiled as


        %reg16384<def> = LDWi <fi#-2>, 0; mem:LD4[FixedStack-2]
I32Regs:%reg16384
        %reg16385<def> = LDWi <fi#-1>, 0; mem:LD4[FixedStack-1]
I32Regs:%reg16385
        %reg16386<def> = COPY %reg16384; I32Regs:%reg16386,16384
        %reg16390<def> = NErrb %reg16384, %reg16385; I1Regs:%reg16390
I32Regs:%reg16384,16385


which just compares ALL BITS of the variables.


Any idea what is causing this and how this could be fixed?

On 29 Sep 2010, at 06:25, Heikki Kultala wrote:
> Our architecture has 1-bit boolean predicate registers.
> 
> I've defined comparison
> 
> 
> def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2),
"", [(set I1Regs:$op3, (setne I32Regs:$op1, I32Regs:$op2))]>;
> 
> 
> 
> 
> But then I end up having the following bug:
> 
> 
> Code
> 
> 
>  %0 = zext i8 %data to i32
>  %1 = zext i16 %crc to i32
>  %2 = xor i32 %1, %0
>  %3 = and i32 %2, 1
>  %4 = icmp eq i32 %3, 0
> 
> 
> which compares the lowest bits of the 2 variables
> 
> 
> ends up being compiled as
> 
> 
>        %reg16384<def> = LDWi <fi#-2>, 0; mem:LD4[FixedStack-2]
I32Regs:%reg16384
>        %reg16385<def> = LDWi <fi#-1>, 0; mem:LD4[FixedStack-1]
I32Regs:%reg16385
>        %reg16386<def> = COPY %reg16384; I32Regs:%reg16386,16384
>        %reg16390<def> = NErrb %reg16384, %reg16385; I1Regs:%reg16390
I32Regs:%reg16384,16385
> 
> 
> which just compares ALL BITS of the variables.



I also have a pattern:

def XORrrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2),
"", [(set I1Regs:$op3, (trunc (xor I32Regs:$op1, I32Regs:$op2)))]>;

Which can do the whole 3-operation code sequence correctly with one operation.

With LLVM 2.7 this correct operation is selected, with LLVM 2.8 the wrong
operation(which compares all bits) is chosen

So this looks like a bug in LLVM 2.8 isel?

On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote:
> On 29 Sep 2010, at 06:25, Heikki Kultala wrote:
> 
>> Our architecture has 1-bit boolean predicate registers.
>> 
>> I've defined comparison
>> 
>> def NErrb : InstTCE<(outs I1Regs:$op3), (ins
I32Regs:$op1,I32Regs:$op2), "", [(set I1Regs:$op3, (setne
I32Regs:$op1, I32Regs:$op2))]>;
>> 
>> But then I end up having the following bug:
>> 
>> Code
>> 
>> %0 = zext i8 %data to i32
>> %1 = zext i16 %crc to i32
>> %2 = xor i32 %1, %0
>> %3 = and i32 %2, 1
>> %4 = icmp eq i32 %3, 0
>> 
>> which compares the lowest bits of the 2 variables
>> ends up being compiled as
>> 
>>       %reg16384<def> = LDWi <fi#-2>, 0;
mem:LD4[FixedStack-2] I32Regs:%reg16384
>>       %reg16385<def> = LDWi <fi#-1>, 0;
mem:LD4[FixedStack-1] I32Regs:%reg16385
>>       %reg16386<def> = COPY %reg16384; I32Regs:%reg16386,16384
>>       %reg16390<def> = NErrb %reg16384, %reg16385;
I1Regs:%reg16390 I32Regs:%reg16384,16385
>> 
>> which just compares ALL BITS of the variables.
> 
> I also have a pattern:
> 
> def XORrrb : InstTCE<(outs I1Regs:$op3), (ins
I32Regs:$op1,I32Regs:$op2), "", [(set I1Regs:$op3, (trunc (xor
I32Regs:$op1, I32Regs:$op2)))]>;
> 
> Which can do the whole 3-operation code sequence correctly with one
operation.
> 
> With LLVM 2.7 this correct operation is selected, with LLVM 2.8 the wrong
operation(which compares all bits) is chosen
> 
> So this looks like a bug in LLVM 2.8 isel?
> 
Hi Heikki,

We need a better example of what's going on. What's the original code?
Also, I don't have access to your back-end's code so it's hard to
tell just from these snippets what's going on. For instance, it's not
clear whether it's the instruction selector that's at fault or if your
.td files have a bug in them somewhere.

-bw