<div dir="ltr">Thanks, Renato!<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 22, 2016 at 8:45 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 15 June 2016 at 23:47, Michael Kuperstein via llvm-dev<br>
<span class="gmail-"><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Step 1: Make -vectorizer-maximize-bandwidth the default. This should improve<br>
> the performance of loops that contain mixed-width types.<br>
<br>
</span>Hi Michael,<br>
<br>
Per target, after investigation, I think this is perfectly fine.<br>
<span class="gmail-"><br></span></blockquote><div><br></div><div>Of course.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
> Step 2: Remove the artificial width limitation altogether, and base the<br>
> vectorization factor decision purely on the cost model. This should allow us<br>
> to get rid of the interleaving code in the loop vectorizer, and get<br>
> interleaving for "free" from the legalizer instead.<br>
<br>
</span>I'm slightly worried about this one, though.<br>
<br></blockquote><div><br></div><div>Me too. :-) </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
The legalizer is a very large mess, with many unknown (or long<br>
forgotten) inter-dependencies and intra-dependencies (with isel,<br>
regalloc, back-end opt passes, etc), which were all mostly annealed<br>
into working by heuristics and hack-fixing stuff. The multiple<br>
attempts at re-writing the instruction selection is one demonstration<br>
of that problem...<br>
<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
So, while I agree with Hal that this will put a good pressure into<br>
improving the cost model (as well as the intra-dependencies), and<br>
that's something very positive, I fear if the jump becomes to far,<br>
we'll either break the world or not jump at all. For example,<br>
FastISel.<br></blockquote><div><br></div><div>How common is the "LoopVectorizer + FastISel + Performance is important" use-case?</div><div>In any case, I agree, this is precisely why I'm not jumping directly to this, and going through the current vectorizer-maximize-bandwidth first.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
I'm not saying we shouldn't do it, but if/when we do it, it would be<br>
*very* beneficial to provide a multi-step migration path for future<br>
targets to move in, not just a multi-step initial migration for the<br>
primary target.<br></blockquote><div><br></div><div>By "multi-step", do you mean the same two steps above, or something more?</div><div>If I understand you correctly, you're suggesting " -vectorizer-maximize-bandwidth" and "-vectorizer-maximize-bandwidth-harder". Then we can move the per-platform defaults to either the "regular" or the "harder" versions independently. Is this what you meant? If so, it makes perfect sense to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Another thing to consider is that the SLP vectorizer can use non-SIMD<br>
FP co-processors (VFP on ARM), which have different costs than SIMD,<br>
but may share the same decision path, especially if we move the<br>
decision lower down into the legalizer.<br>
<br>
Also, there are hidden costs between the different units in sharing<br>
the registers or moving between, and that is not mapped into the<br>
current cost model entirely (only via heuristics). This may not be a<br>
problem for Intel, but it certainly will be for ARM/AArch64.<br></blockquote><div><br></div><div>I agree this is a problem, but it seems like it should be orthogonal to what I'm suggesting. I probably don't understand the background well enough, though.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
I had a plan 3 years ago to look into that, but never got around doing<br>
it. Maybe it's about time I did... :)<br>
<br>
Finally, if you need pre-testing and benchmarking, let me know and I<br>
can spare some time to help you. I'll be glad to be copied on the<br>
reviews and will do my best to help.<br></blockquote><div><br></div><div>That wold be great! I'm going to start with X86, mostly because that's the platform I'm most familiar with. But once it works on X86 (hopefully), I'll definitely need help with other platforms, both in terms of the cost model and benchmarking.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
All in all, I don't think we'll get anything for free on this change.<br>
There will be a cost, and it will be different on different targets,<br>
but it may very well be a cost worth taking. I don't know enough yet<br>
to have an opinion.<br>
<br></blockquote><div><br></div><div>Maybe "free" wasn't the right word to use here. :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
cheers,<br>
--renato<br>
</blockquote></div><br></div></div>