Dilan Manatunga via llvm-dev
2017-Jul-21 18:13 UTC
[llvm-dev] Issue with DAG legalization of brcond, setcc, xor
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>
Krzysztof Parzyszek via llvm-dev
2017-Jul-21 18:23 UTC
[llvm-dev] Issue with DAG legalization of brcond, setcc, xor
Legalization transforms the code to only use types and operations that the target declares as natively supported (i.e. "legal"). The DAG combiner, on the other hand tries to simplify the code. The lowering process happens in several stages where the two types of transformations alternate. It may happen that a root node of a certain sub-tree will be transformed from setcc to xor then back to setcc, but the entire sub-tree will change as well. -Krzysztof On 7/21/2017 1:13 PM, Dilan Manatunga via llvm-dev wrote:> 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 > <mailto: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 > <mailto: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> > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Dilan Manatunga via llvm-dev
2017-Jul-21 19:40 UTC
[llvm-dev] Issue with DAG legalization of brcond, setcc, xor
Why would converting a setcc to xor or vice versa change the sub-trees at all. The inputs to both instructions remain the same. I looked through the codes where both legalization occurs, and it doesn't seem like any sub-tree modifications should be happening. I guess the thing is I want to understand why this happens. Is there a reason we want all branch inputs to be setcc operations, instead of a simple xor? -Dilan P.S. Still don't get your messages in my inbox. On Fri, Jul 21, 2017 at 11:13 AM Dilan Manatunga <manatunga at gmail.com> wrote:> 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/4d89324b/attachment.html>
Craig Topper via llvm-dev
2017-Jul-21 19:47 UTC
[llvm-dev] Issue with DAG legalization of brcond, setcc, xor
I think this is because branch instructions typically depend on a flag in a condition code or flag register. While an instruction like xor writes its output to a normal register. So the setcc reflects an operation that updates flags. ~Craig On Fri, Jul 21, 2017 at 12:40 PM, Dilan Manatunga via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Why would converting a setcc to xor or vice versa change the sub-trees at > all. The inputs to both instructions remain the same. I looked through the > codes where both legalization occurs, and it doesn't seem like any sub-tree > modifications should be happening. > > I guess the thing is I want to understand why this happens. Is there a > reason we want all branch inputs to be setcc operations, instead of a > simple xor? > > -Dilan > > P.S. Still don't get your messages in my inbox. > > On Fri, Jul 21, 2017 at 11:13 AM Dilan Manatunga <manatunga at gmail.com> > wrote: > >> 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> >>>> >>>> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170721/82949e63/attachment.html>
Krzysztof Parzyszek via llvm-dev
2017-Jul-21 20:35 UTC
[llvm-dev] Issue with DAG legalization of brcond, setcc, xor
Yes, it seems that nothing else has changed. The presence of xor with both operands being results of setcc could have triggered some transformation in the combiner, but the only outcome that it was able to produce was again setcc with the same operands as the xor. There are a number of restrictions that both, the legalizer and the combiner work under, and it is possible that their changes will in the end amount to something trivial. Make sure that all operations and types that are legal on your target are properly marked as such. -Krzysztof On 7/21/2017 2:40 PM, Dilan Manatunga via llvm-dev wrote:> Why would converting a setcc to xor or vice versa change the sub-trees > at all. The inputs to both instructions remain the same. I looked > through the codes where both legalization occurs, and it doesn't seem > like any sub-tree modifications should be happening. > > I guess the thing is I want to understand why this happens. Is there a > reason we want all branch inputs to be setcc operations, instead of a > simple xor? > > -Dilan > > P.S. Still don't get your messages in my inbox. > > On Fri, Jul 21, 2017 at 11:13 AM Dilan Manatunga <manatunga at gmail.com > <mailto:manatunga at gmail.com>> wrote: > > 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 <mailto: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 <mailto: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> > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation