<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Dec 4, 2014, at 11:10 AM, Quentin Colombet <<a href="mailto:qcolombet@apple.com">qcolombet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hi,</div><br><div><div>On Dec 4, 2014, at 9:19 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 4, 2014 at 9:05 AM, Kuperstein, Michael M<span class="Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:michael.m.kuperstein@intel.com" target="_blank">michael.m.kuperstein@intel.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">It looks like in the cited PR it was the best sequence, but I agree with you, it may not be the case globally.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">Which stalls are you talking about? I think domain crossing shouldn’t be a problem in this case, as the zexts would imply you want to be in the integer domain.</span></p></blockquote><div><br></div><div>The domain cross as I understand it (and feel free to shed more detailed light on this aspect of Intel chips if you can, but I've failed to get any better clarification from Intel folks in the past) is more problematic than that.</div><div><br></div><div>It stems from separate execution units of some form (which form, and whether the "ports" as described in modern Intel manuals attach to them or are fixed to them isn't really important). Moving data in a register from one unit to the other unit stalls. This is just as true (if not more true) moving data from an integer xmm register into a gpr as it is moving data produced in the floating point vector unit to an input of an integer vector unit instruction.</div><div><br></div><div>Previously, the *primary* cause of vector shuffle performance problems in the x86 backend was because it heavily relied on pextr and pinsr sequences to manually extract and insert the elements into the desired positions. But the slow downs were vastly out of proportion to the number of instructions different. The best explanation, and one supported by various timings indications in Agners and elsewhere, is that there is a rather massive penalty incurred in sequences of these instructions. In my benchmarking, I routinely saw this penalty be much higher than that of domain crossing between integer and floating point units on Intel chips. On AMD chips, the penalties were more even, but were also both significantly higher than on Intel chips.</div><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">Regarding systematic testing – no, since this is a fairly specific pattern.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">Do you have any examples in mind that will match this, but be negatively impacted?</span></p></blockquote><div><br></div><div>I would start off with checking LNT, maybe SPEC (although I'm loath to trust SPEC numbers for this kind of change).</div><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">Regarding patterns impacted by this - if I understand correctly, the pattern that this was introduced to catch was precisely the one the LIT test checks – 64-bit GEPs that use indexes extracted from a 4xi32 vector. There’s a rdar linked to the test. Quentin, do you think it’s worth checking what the impact of this is on the original issue?</span></p><div><br></div></blockquote></div></div></div></blockquote><div><br></div><div>I’ll have a look at the original radar and I’ll let you know.</div></div></div></blockquote><div><br></div><div>This transformation implies a 1% regression there.</div><div>I am not sure if this is the transformation itself or if it uncovers a poor codegen for some shuffle.</div><div>Indeed, in this specific example, instead of having vpextr + 1 mov from XMM to GPR, we have a vpshuf + 2 mov from XMM to GPR.</div><div><br></div><div>Trying to produce a reduce test case.</div><div><br></div><div>Cheers,</div><div>Q.</div><br><blockquote type="cite"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">This also might be uncovered by checking the LNT results.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">All this said, I'm not certain of anything here. Maybe this is a strict win. I just think it needs more broad measurements than the PR shows.</div></div></blockquote><br></div>I agree with Chandler and in fact I thought that has been done. Therefore, by all means, please do performance measurements.<div><br></div><div>Thanks,</div><div>Q.</div>_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a></div></blockquote></div><br></body></html>