<div dir="ltr">Hi Nadav,<div><br></div><div style>Thanks for the quick and unambiguous response.</div><div style><br></div><div style>One thing - I thought the rationale of SelectionDAG was that it did optimizations that were implicit in the IR - that is, all optimizations that change IR should be done on the IR, and only what's left over (because of IR's high level) should be done in DAGCombine.</div>
<div style><br></div><div style>Has the rationale changed here, or is it just the "least worst" place?</div><div style><br></div><div style>Cheers,</div><div style><br></div><div style>James</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On 5 August 2013 18:53, Nadav Rotem <span dir="ltr"><<a href="mailto:nrotem@apple.com" target="_blank">nrotem@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>Hi James, </div><div><br></div><div>We don’t generate new shuffles because we don’t have a good cost model for shuffles.  The last time we discussed it was in this thread:</div><div>
<br></div><div><a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130429/173217.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130429/173217.html</a></div><div><br>
</div><div>Also, InstCombine should canonicalize, not optimize.  </div><div><br></div><div><div class="im"><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;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div dir="ltr"><div><div>Now, there are many clever things InstCombine could do with shufflevector. The two I have in my queue at the moment are:</div><div>  1) Where there's an insertelement into vector B that comes direct from an extractelement of vector A, and vector A's length is less than vector B's, create a shuffle to extend A then another shuffle to perform the equivalent of extract/insertelement.</div>
</div></div></div></blockquote><div><br></div></div><div>This won’t work for x86 because it has vector registers of different sizes (512, 256 and 128).  If this is profitable it should be done per-target in SelectionDAG where the target information is available. </div>
<div class="im"><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;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div dir="ltr"><div><div>  2) Where two shuffles' masks could combine to make a monotonically increasing sequence, perform the combination.</div><div><br></div></div></div></div></blockquote><div><br></div></div><div>
This is okay, assuming that:</div><div><br></div><div>1.  There are no additional users to the shuffles.</div><div>2.  The new shuffle is a NOP, and can be deleted. </div><div class="im"><div><br></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;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div dir="ltr"><div><div>Both of the above have caveats that can't be said in one sentence, but they're basically rewriting common front-end patterns to make shuffles that correspond to vector extension (VEXT instructions in ARM) or concatenation of subvectors.</div>
<div><br></div><div>Now, I think these would both be of use to any architecture that has decent shufflevector support, and InstCombine seems like the right place for it. But if InstCombine is supposed to be conservative, where should these optimizations go?</div>
<div><br></div></div></div></div></blockquote><div><br></div></div><div>DAGCombine. </div><div><br></div><div>Thanks,</div><div>Nadav</div></div><br></div></blockquote></div><br></div>