llvm dev - Jul 2017 - Issue with DAG legalization of brcond, setcc, xor

Hi,

I am having some issues with how some of the instructions are being
legalized.
So this is my intial basic block. The area of concern is the last three
instructions. I will pick and choose debug output to keep this small.

SelectionDAG has 36 nodes:
  t0: ch = EntryToken
          t6: i32,ch = CopyFromReg t0, Register:i32 %vreg507
              t2: i32,ch = CopyFromReg t0, Register:i32 %vreg17
            t4: i32 = or t2, Constant:i32<256>
          t9: i32 = shl t4, Constant:i32<2>
        t10: i32 = add t6, t9
        t12: i32,ch = CopyFromReg t0, Register:i32 %vreg79
        t15: i32,ch = CopyFromReg t0, Register:i32 %vreg1
      t16: ch = llvm.tpu.dma.write.1KB.async t0,
TargetConstant:i32<4602>, t10, t12, t15
              t18: i32,ch = CopyFromReg t0, Register:i32 %vreg166
            t20: i32 = AssertZext t18, ValueType:ch:i1
          t23: i1 = setcc t20, Constant:i32<0>, seteq:ch
            t25: i32,ch = CopyFromReg t0, Register:i32 %vreg396
          t28: i1 = setcc t25, Constant:i32<255>, setugt:ch
        t29: i1 = and t23, t28
      t37: i1 = setcc t29, Constant:i1<-1>, setne:ch
    t33: ch = brcond t16, t37, BasicBlock:ch<if.end65.1 0x7097330>
  t35: ch = br t33, BasicBlock:ch<if.then64.1 0x7097280>
 Here we see that the settcc has been legalized to xor, which I am fine with..
Legalizing: t37: i1 = setcc t29, Constant:i1<-1>, setne:ch

Combining: t37: i1 = setcc t29, Constant:i1<-1>, setne:ch
 ... into: t38: i1 = xor t29, Constant:i1<-1>

However, the issue I have is that we than try to legalize and combin
the brcond again.

Legalizing: t33: ch = brcond t16, t38, BasicBlock:ch<if.end65.1 0x7097330>
Combining: t33: ch = brcond t16, t38, BasicBlock:ch<if.end65.1 0x7097330>

What the debug output doesn't show you is that when try to combine the
brcond again, we end up modifying the xor we created to setcc again.

      t40: i32 = setcc t29, Constant:i1<-1>, setne:ch

But the issue is now the setcc returns a 32-bit type.

I did some tracing and from what I can tell the visitBRCOND function
in DAGCombiner is responsible for this change. It sees that the brcond
has only one use that is an xor. Later on, it also sees that the two
operands to the xor are neither setcc, so it converts the xor to setcc
again. I would be fine with this, but when it tries to find the output
type of the setcc, it chooses i32 instead of i1. Again, it seems this
happens from the line of code that is:

 SetCCVT = getSetCCResultType(SetCCVT)

All that function does though is return the data type for pointers.

Well, to my questions I guess. Why is this happening? Isn't it kinda
silly to convert a setcc to an xor, and then convert it back to a
slightly different output setcc. And how can I prevent this, or fix
it, since my conditional branches only support having single bit
inputs.

Thanks,

-Dilan

PS Here is optimized DAG in case you were wondering.

Combining: t0: ch = EntryToken Optimized legalized selection DAG: BB#212
'merge_sort:for.cond.cleanup39.1' SelectionDAG has 36 nodes: t0: ch
EntryToken t6: i32,ch = CopyFromReg t0, Register:i32 %vreg507 t2: i32,ch
CopyFromReg t0, Register:i32 %vreg17 t4: i32 = or t2, Constant:i32<256>
t9:
i32 = shl t4, Constant:i32<2> t10: i32 = add t6, t9 t12: i32,ch
CopyFromReg t0, Register:i32 %vreg79 t15: i32,ch = CopyFromReg t0,
Register:i32 %vreg1 t16: ch = llvm.tpu.dma.write.1KB.async t0,
TargetConstant:i32<4602>, t10, t12, t15 t18: i32,ch = CopyFromReg t0,
Register:i32 %vreg166 t20: i32 = AssertZext t18, ValueType:ch:i1 t23: i1 setcc
t20, Constant:i32<0>, seteq:ch t25: i32,ch = CopyFromReg t0,
Register:i32 %vreg396 t28: i1 = setcc t25, Constant:i32<255>, setugt:ch
t29: i1 = and t23, t28 t40: i32 = setcc t29, Constant:i1<-1>, setne:ch
t33:
ch = brcond t16, t40, BasicBlock:ch<if.end65.1 0x7097330> t35: ch = br
t33,
BasicBlock:ch<if.then64.1 0x7097280>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170720/a221223f/attachment.html>

On 7/19/2017 9:28 PM, Dilan Manatunga via llvm-dev
wrote:
> Again, it seems this happens from the line of code that is:
> 
>   SetCCVT = getSetCCResultType(SetCCVT)
> 
> All that function does though is return the data type for pointers.
It gets the result from TargetLowering.  Does your target override this 
function?

-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

For some reason I didn't get Krzysztof Parzyszek e-mail in my inbox, but
thanks for the fact I can override the getSetCCResultType. Didn't even
think of that.

-Dilan

On Wed, Jul 19, 2017 at 7:28 PM Dilan Manatunga <manatunga at gmail.com>
wrote:
> Hi,
>
> I am having some issues with how some of the instructions are being
> legalized.
> So this is my intial basic block. The area of concern is the last three
> instructions. I will pick and choose debug output to keep this small.
>
> SelectionDAG has 36 nodes:
>   t0: ch = EntryToken
>           t6: i32,ch = CopyFromReg t0, Register:i32 %vreg507
>               t2: i32,ch = CopyFromReg t0, Register:i32 %vreg17
>             t4: i32 = or t2, Constant:i32<256>
>           t9: i32 = shl t4, Constant:i32<2>
>         t10: i32 = add t6, t9
>         t12: i32,ch = CopyFromReg t0, Register:i32 %vreg79
>         t15: i32,ch = CopyFromReg t0, Register:i32 %vreg1
>       t16: ch = llvm.tpu.dma.write.1KB.async t0,
TargetConstant:i32<4602>, t10, t12, t15
>               t18: i32,ch = CopyFromReg t0, Register:i32 %vreg166
>             t20: i32 = AssertZext t18, ValueType:ch:i1
>           t23: i1 = setcc t20, Constant:i32<0>, seteq:ch
>             t25: i32,ch = CopyFromReg t0, Register:i32 %vreg396
>           t28: i1 = setcc t25, Constant:i32<255>, setugt:ch
>         t29: i1 = and t23, t28
>       t37: i1 = setcc t29, Constant:i1<-1>, setne:ch
>     t33: ch = brcond t16, t37, BasicBlock:ch<if.end65.1 0x7097330>
>   t35: ch = br t33, BasicBlock:ch<if.then64.1 0x7097280>
>  Here we see that the settcc has been legalized to xor, which I am fine
with..
> Legalizing: t37: i1 = setcc t29, Constant:i1<-1>, setne:ch
>
> Combining: t37: i1 = setcc t29, Constant:i1<-1>, setne:ch
>  ... into: t38: i1 = xor t29, Constant:i1<-1>
>
> However, the issue I have is that we than try to legalize and combin the
brcond again.
>
> Legalizing: t33: ch = brcond t16, t38, BasicBlock:ch<if.end65.1
0x7097330>
> Combining: t33: ch = brcond t16, t38, BasicBlock:ch<if.end65.1
0x7097330>
>
> What the debug output doesn't show you is that when try to combine the
brcond again, we end up modifying the xor we created to setcc again.
>
>       t40: i32 = setcc t29, Constant:i1<-1>, setne:ch
>
> But the issue is now the setcc returns a 32-bit type.
>
> I did some tracing and from what I can tell the visitBRCOND function in
DAGCombiner is responsible for this change. It sees that the brcond has only one
use that is an xor. Later on, it also sees that the two operands to the xor are
neither setcc, so it converts the xor to setcc again. I would be fine with this,
but when it tries to find the output type of the setcc, it chooses i32 instead
of i1. Again, it seems this happens from the line of code that is:
>
>  SetCCVT = getSetCCResultType(SetCCVT)
>
> All that function does though is return the data type for pointers.
>
> Well, to my questions I guess. Why is this happening? Isn't it kinda
silly to convert a setcc to an xor, and then convert it back to a slightly
different output setcc. And how can I prevent this, or fix it, since my
conditional branches only support having single bit inputs.
>
> Thanks,
>
> -Dilan
>
> PS Here is optimized DAG in case you were wondering.
>
> Combining: t0: ch = EntryToken Optimized legalized selection DAG: BB#212
> 'merge_sort:for.cond.cleanup39.1' SelectionDAG has 36 nodes: t0: ch
> EntryToken t6: i32,ch = CopyFromReg t0, Register:i32 %vreg507 t2: i32,ch
> CopyFromReg t0, Register:i32 %vreg17 t4: i32 = or t2,
Constant:i32<256> t9:
> i32 = shl t4, Constant:i32<2> t10: i32 = add t6, t9 t12: i32,ch >
CopyFromReg t0, Register:i32 %vreg79 t15: i32,ch = CopyFromReg t0,
> Register:i32 %vreg1 t16: ch = llvm.tpu.dma.write.1KB.async t0,
> TargetConstant:i32<4602>, t10, t12, t15 t18: i32,ch = CopyFromReg t0,
> Register:i32 %vreg166 t20: i32 = AssertZext t18, ValueType:ch:i1 t23: i1
> setcc t20, Constant:i32<0>, seteq:ch t25: i32,ch = CopyFromReg t0,
> Register:i32 %vreg396 t28: i1 = setcc t25, Constant:i32<255>,
setugt:ch
> t29: i1 = and t23, t28 t40: i32 = setcc t29, Constant:i1<-1>,
setne:ch t33:
> ch = brcond t16, t40, BasicBlock:ch<if.end65.1 0x7097330> t35: ch =
br t33,
> BasicBlock:ch<if.then64.1 0x7097280>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170721/ccfe0fa8/attachment.html>

But isn't kinda silly that we transform to xor and then we transform it
back. What is the advantage in doing so? Also, since we do that method, I
now have to introduce setcc patterns for i1 values, instead of being able
to just use logical pattern operators like not.

-Dilan

On Fri, Jul 21, 2017 at 11:00 AM Dilan Manatunga <manatunga at gmail.com>
wrote:
> For some reason I didn't get Krzysztof Parzyszek e-mail in my inbox,
but
> thanks for the fact I can override the getSetCCResultType. Didn't even
> think of that.
>
> -Dilan
>
> On Wed, Jul 19, 2017 at 7:28 PM Dilan Manatunga <manatunga at
gmail.com>
> wrote:
>
>> Hi,
>>
>> I am having some issues with how some of the instructions are being
>> legalized.
>> So this is my intial basic block. The area of concern is the last three
>> instructions. I will pick and choose debug output to keep this small.
>>
>> SelectionDAG has 36 nodes:
>>   t0: ch = EntryToken
>>           t6: i32,ch = CopyFromReg t0, Register:i32 %vreg507
>>               t2: i32,ch = CopyFromReg t0, Register:i32 %vreg17
>>             t4: i32 = or t2, Constant:i32<256>
>>           t9: i32 = shl t4, Constant:i32<2>
>>         t10: i32 = add t6, t9
>>         t12: i32,ch = CopyFromReg t0, Register:i32 %vreg79
>>         t15: i32,ch = CopyFromReg t0, Register:i32 %vreg1
>>       t16: ch = llvm.tpu.dma.write.1KB.async t0,
TargetConstant:i32<4602>, t10, t12, t15
>>               t18: i32,ch = CopyFromReg t0, Register:i32 %vreg166
>>             t20: i32 = AssertZext t18, ValueType:ch:i1
>>           t23: i1 = setcc t20, Constant:i32<0>, seteq:ch
>>             t25: i32,ch = CopyFromReg t0, Register:i32 %vreg396
>>           t28: i1 = setcc t25, Constant:i32<255>, setugt:ch
>>         t29: i1 = and t23, t28
>>       t37: i1 = setcc t29, Constant:i1<-1>, setne:ch
>>     t33: ch = brcond t16, t37, BasicBlock:ch<if.end65.1
0x7097330>
>>   t35: ch = br t33, BasicBlock:ch<if.then64.1 0x7097280>
>>  Here we see that the settcc has been legalized to xor, which I am fine
with..
>> Legalizing: t37: i1 = setcc t29, Constant:i1<-1>, setne:ch
>>
>> Combining: t37: i1 = setcc t29, Constant:i1<-1>, setne:ch
>>  ... into: t38: i1 = xor t29, Constant:i1<-1>
>>
>> However, the issue I have is that we than try to legalize and combin
the brcond again.
>>
>> Legalizing: t33: ch = brcond t16, t38, BasicBlock:ch<if.end65.1
>> 0x7097330> Combining: t33: ch = brcond t16, t38,
BasicBlock:ch<if.end65.1
>> 0x7097330>
>>
>> What the debug output doesn't show you is that when try to combine
the brcond again, we end up modifying the xor we created to setcc again.
>>
>>       t40: i32 = setcc t29, Constant:i1<-1>, setne:ch
>>
>> But the issue is now the setcc returns a 32-bit type.
>>
>> I did some tracing and from what I can tell the visitBRCOND function in
DAGCombiner is responsible for this change. It sees that the brcond has only one
use that is an xor. Later on, it also sees that the two operands to the xor are
neither setcc, so it converts the xor to setcc again. I would be fine with this,
but when it tries to find the output type of the setcc, it chooses i32 instead
of i1. Again, it seems this happens from the line of code that is:
>>
>>  SetCCVT = getSetCCResultType(SetCCVT)
>>
>> All that function does though is return the data type for pointers.
>>
>> Well, to my questions I guess. Why is this happening? Isn't it
kinda silly to convert a setcc to an xor, and then convert it back to a slightly
different output setcc. And how can I prevent this, or fix it, since my
conditional branches only support having single bit inputs.
>>
>> Thanks,
>>
>> -Dilan
>>
>> PS Here is optimized DAG in case you were wondering.
>>
>> Combining: t0: ch = EntryToken Optimized legalized selection DAG:
BB#212
>> 'merge_sort:for.cond.cleanup39.1' SelectionDAG has 36 nodes:
t0: ch >> EntryToken t6: i32,ch = CopyFromReg t0, Register:i32 %vreg507
t2: i32,ch >> CopyFromReg t0, Register:i32 %vreg17 t4: i32 = or t2,
Constant:i32<256> t9:
>> i32 = shl t4, Constant:i32<2> t10: i32 = add t6, t9 t12: i32,ch
>> CopyFromReg t0, Register:i32 %vreg79 t15: i32,ch = CopyFromReg t0,
>> Register:i32 %vreg1 t16: ch = llvm.tpu.dma.write.1KB.async t0,
>> TargetConstant:i32<4602>, t10, t12, t15 t18: i32,ch = CopyFromReg
t0,
>> Register:i32 %vreg166 t20: i32 = AssertZext t18, ValueType:ch:i1 t23:
i1 >> setcc t20, Constant:i32<0>, seteq:ch t25: i32,ch = CopyFromReg
t0,
>> Register:i32 %vreg396 t28: i1 = setcc t25, Constant:i32<255>,
setugt:ch
>> t29: i1 = and t23, t28 t40: i32 = setcc t29, Constant:i1<-1>,
setne:ch t33:
>> ch = brcond t16, t40, BasicBlock:ch<if.end65.1 0x7097330> t35: ch
= br t33,
>> BasicBlock:ch<if.then64.1 0x7097280>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170721/444ae709/attachment.html>