<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Fiona,</div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jan 16, 2015, at 7:56 AM, Fiona Glaser <<a href="mailto:fglaser@apple.com" class="">fglaser@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">Loading 2 2x32-bit float vectors into the bottom half of a 256-bit vector</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">produced suboptimal code in AVX2 mode with certain IR combinations.</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">In particular, the IR optimizer folded 2f32 + 2f32 -> 4f32, 4f32 + 4f32</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">(undef) -> 8f32 into a 2f32 + 2f32 -> 8f32, which seems more canonical,</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">but then mysteriously generated rather bad code; the movq/movhpd combination</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">didn't match.</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">The problem lay in the BUILD_VECTOR optimization path. The 2f32 inputs</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">would get promoted to 4f32 by the type legalizer, eventually resulting</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">in a BUILD_VECTOR on two 4f32 into an 8f32. The BUILD_VECTOR then, recognizing</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">these were both half the output size, concatted them and then produced</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">a shuffle. However, the resulting concat + shuffle was more complex than</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">it should be; in the case where the upper half of the output is undef, we</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">probably want to generate shuffle + concat instead.</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;" class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>Are we sure that BUILD_VECTOR is the only place that can lead to your pathological case? </div><div>I feel such case may be present because of other combine/fold where you end up with concat_vectors followed by a shuffle with an undef instead of a shuffle followed by a concat with undef.</div><div><br class=""></div><div>It seems to me that this canonicalization belongs to <span style="font-family: Menlo;" class="">visitVECTOR_SHUFFLE </span>instead.</div><div><br class=""></div><div>Some comments on the patch itself:</div><div><br class=""></div><div><br class=""></div><div><div>+ bool ShuffleUpperUndef = true;</div><div>+ for (unsigned i = NumInScalars / 2; i != NumInScalars; ++i)</div><div>+ if (Mask[i] >= 0)</div><div>+ ShuffleUpperUndef = false;</div><div class=""><br class=""></div><div class="">bool ShuffleUpperUndef = std::all_of(&Mask[NumInScalars / 2], &Mask[NumInScalars], [](int i){ return i == 0; });</div><div class=""><br class=""></div></div><div><br class=""></div><div><div>+ for(unsigned i = 0; i < NumInScalars / 2; i++)</div><div>+ Mask.pop_back();</div><div class=""><br class=""></div><div class="">Mask.resize(NumInScalars / 2);</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">+ return DAG.getNode(ISD::CONCAT_VECTORS, dl, VT, VecIn1, VecIn2);</div><div class="">+ }</div><div class="">+ else {</div><div class="">+ VecIn1 = DAG.getNode(ISD::CONCAT_VECTORS, dl, VT, VecIn1, VecIn2);</div><div class="">+ VecIn2 = SDValue(nullptr, 0);</div><div class="">+ }</div></div><div class=""><br class=""></div><div class="">The else is useless since the true branch ends up with a return.</div><div class=""><br class=""></div><div class=""><div class="">+; CHECK: foo</div></div><div class=""><br class=""></div><div class="">use CHECK-LABEL</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Mehdi</div><div class=""><br class=""></div></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">This enhancement results in the optimizer correctly producing the optimal</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">movq + movhpd sequence for all three variations on this IR, even with AVX2.</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">I've included a test case.</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">Radar link: <a href="rdar://problem/13326338" class="">rdar://problem/13326338</a></div><div class=""><br class=""></div><div class=""></div></div><span id="cid:7BB762EF-4CC0-4793-8384-D379908E170A@apple.com"><patch.diff></span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""></div></div>_______________________________________________<br class="">llvm-commits mailing list<br class=""><a href="mailto:llvm-commits@cs.uiuc.edu" class="">llvm-commits@cs.uiuc.edu</a><br class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits<br class=""></div></blockquote></div><br class=""></body></html>