<div dir="ltr">There's a check for this in WidenVecRes_SETCC, but we're not reaching it because we end up in a custom widening handler for SETCC.<div><br></div><font face="monospace"> // The input and output types often differ here, and it could be that while<br> // we'd prefer to widen the result type, the input operands have been split.<br> // In this case, we also need to split the result of this node as well.<br> if (getTypeAction(InVT) == TargetLowering::TypeSplitVector) {<br> SDValue SplitVSetCC = SplitVecOp_VSETCC(N);<br> SDValue Res = ModifyToType(SplitVSetCC, WidenVT);<br> return Res;<br> }</font><div><font face="monospace"><br></font></div><div><font face="monospace"><br></font><div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 26, 2021 at 11:18 AM Krzysztof Parzyszek <<a href="mailto:kparzysz@quicinc.com">kparzysz@quicinc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_9108389898457847408WordSection1">
<p class="MsoNormal">I was able to come up with a different testcase that shows the same issue (where lack of context causes trouble):<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">define <32 x i32> @fred(<32 x i32> %a0, <32 x i32> %a1) #0 {<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">b0:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""> %v0 = bitcast <32 x i32> %a0 to <32 x float><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""> %v1 = bitcast <32 x i32> %a1 to <32 x float><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""> %v2 = fcmp ogt <32 x float> %v0, %v1<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""> %v3 = select <32 x i1> %v2, <32 x float> zeroinitializer, <32 x float> %v0<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""> %v4 = bitcast <32 x float> %v3 to <32 x i32><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""> ret <32 x i32> %v4<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">}<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">attributes #0 = { nounwind "target-cpu"="hexagonv66" "target-features"="+hvxv66,+hvx-length128b" }</span><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">You can run this with “llc -march=hexagon < testcase.ll” and see it get stuck.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Float vectors are illegal, and they need to be scalarized. Integer vectors are legal, moreover we legalize short vectors by widening them to full vectors. Boolean vectors (i.e. vNi1) are also widened accordingly if necessary, and herein
lies the problem:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">First, this happens:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span lang="DE" style="font-family:"Courier New"">Legalizing node: t8: v32i1 = setcc t5, t6, setogt:ch<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">Analyzing result type: v32i1<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">Legal result type<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">Analyzing operand: t5: v32f32 = bitcast t2<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:red">Split</span><span style="font-family:"Courier New""> node operand: t8: v32i1 = setcc t5, t6, setogt:ch</span><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">But then (v16i1 is not legal)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">Legalizing node: t449: v16i1 = setcc t26, t447, setogt:ch<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">Analyzing result type: v16i1<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:red">Widen</span><span style="font-family:"Courier New""> node result 0: t449: v16i1 = setcc t26, t447, setogt:ch</span><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">End we end up in an infinite loop, where we decide to widen the result of the short setcc, then to split the operands of the widened one, and so on…<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">If, at the time of checking the v16i1, we knew that it came from a setcc that needs to be scalarized, we would not tell the legalizer to widen. But we don’t know where the v16i1 came from, so we assume it came from an integer operation
and we decide to widen based only on the type itself. If we decided to scalarize v16i1, we may end up with the reverse problem, where the integer operands need to be widened, but the result wants to be scalarized… We could decide to scalarize everything
that is not legal, but that would defeat the purpose of widening altogether (and would be bad for performance).<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Consolas">-- </span>
<span style="font-size:9pt;font-family:Consolas"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:8pt;font-family:Consolas">Krzysztof Parzyszek
<a href="mailto:kparzysz@quicinc.com" target="_blank"><span style="color:rgb(5,99,193)">kparzysz@quicinc.com</span></a> AI tools development<u></u><u></u></span></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> <b>On Behalf Of
</b>Krzysztof Parzyszek via llvm-dev<br>
<b>Sent:</b> Tuesday, March 23, 2021 1:09 PM<br>
<b>To:</b> Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</a>><br>
<b>Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> [EXT] Re: [llvm-dev] SDAG: Type legalization woes (context insensitivity)<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I had to go digging around a bit. At the time we decided to go with something that worked, and now I thought I remembered enough about it…<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I cannot find the testcase, so I guess I’ll have to wait and see if the problem reappears.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Sorry for the noise.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Consolas">-- <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:8pt;font-family:Consolas">Krzysztof Parzyszek
<a href="mailto:kparzysz@quicinc.com" target="_blank"><span style="color:rgb(5,99,193)">kparzysz@quicinc.com</span></a> AI tools development<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</a>>
<br>
<b>Sent:</b> Monday, March 22, 2021 2:59 PM<br>
<b>To:</b> Krzysztof Parzyszek <<a href="mailto:kparzysz@quicinc.com" target="_blank">kparzysz@quicinc.com</a>><br>
<b>Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> [EXT] Re: [llvm-dev] SDAG: Type legalization woes (context insensitivity)<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">Where's the call to SetWidenedVector coming from? I would expect your case to go through WidenVecOp_SETCC which creates a wide setcc, but appends an extract_subvector before returning.<u></u><u></u></p>
<div>
<p class="MsoNormal">~Craig<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Mar 22, 2021 at 12:52 PM Krzysztof Parzyszek <<a href="mailto:kparzysz@quicinc.com" target="_blank">kparzysz@quicinc.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal">We’re hitting the first one in this function (I’m trying to get a testcase that would reproduce this crash):<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">void DAGTypeLegalizer::SetWidenedVector(SDValue Op, SDValue Result) {</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Courier New""> assert(Result.getValueType() ==</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Courier New""> TLI.getTypeToTransformTo(*DAG.getContext(), Op.getValueType()) &&</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Courier New""> "Invalid type for widened vector");</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Courier New""> AnalyzeNewValue(Result);</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Courier New""> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Courier New""> auto &OpIdEntry = WidenedVectors[getTableId(Op)];</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Courier New""> assert((OpIdEntry == 0) && "Node already widened!");</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Courier New""> OpIdEntry = getTableId(Result);</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">}</span><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Yes, v64i1 is legal, but it fails the condition ‘getTypeToTransformTo(v32i1) == v64i1’.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Consolas">--
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:8pt;font-family:Consolas">Krzysztof Parzyszek
<a href="mailto:kparzysz@quicinc.com" target="_blank"><span style="color:rgb(5,99,193)">kparzysz@quicinc.com</span></a> AI tools development</span><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</a>>
<br>
<b>Sent:</b> Monday, March 22, 2021 1:55 PM<br>
<b>To:</b> Krzysztof Parzyszek <<a href="mailto:kparzysz@quicinc.com" target="_blank">kparzysz@quicinc.com</a>><br>
<b>Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> [EXT] Re: [llvm-dev] SDAG: Type legalization woes (context insensitivity)<u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">Is v64i1 not a legal type for Hexagon? What assertion are you hitting?<u></u><u></u></p>
</div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">~Craig<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Mar 22, 2021 at 11:30 AM Krzysztof Parzyszek via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<p class="MsoNormal">Summary: some types need more contextual information to properly legalize than what TLI queries give.<br>
<br>
Example: consider v32i1:<br>
1. v32i1 = compare v32i32, v32i32 ; all good<br>
2. v32i1 = compare v32i16, v32i16 ; problem: v32i16 not legal, but v32i1 is<br>
<br>
The type v32i1 is legal because there it can be represented in a register and can be a result of a legal comparison of legally-typed vectors. But it can also be a result of comparing illegally-typed vectors, which causes a problem.<br>
The type legalization first looks at the value type, sees v32i1, takes note that it's legal. Then, for the second case, it will attempt to legalize the operand types, but that action would also cause the result type to change (e.g. widen everything: v32i16->v64i16,
v32i1->v64i1), hitting an assertion.<br>
<br>
I'm seeing this issue on Hexagon, but it seems to be fairly generic in its nature. Has anyone else experienced this?<br>
<br>
I want to fix this somehow. My current idea is to simply allow a known legal type to be replaced with another legal type, but there may be different approaches, like using SDValue in the TLI.whatAbouThisType family.<br>
<br>
Does anybody have concerns, thoughts?<br>
<br>
--<br>
Krzysztof Parzyszek <a href="mailto:kparzysz@quicinc.com" target="_blank">kparzysz@quicinc.com</a> AI tools development<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote></div>