<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 23, 2015 at 2:24 PM, James Molloy <span dir="ltr"><<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I agree with Chandler's comment in the review thread. I'm actively working on a patch at the moment (it has a couple of correctness issues still to resolve) to do this - identify operations that could be truncated and performed in a narrower type, and update the cost model to understand this.</div><div><br></div><div>As far as I can see, what I have is a superset of your patch.</div></div></blockquote><div><br></div><div>Thank you for the information! I understand that your optimization needs larger VF during vectorization, but increasing VF not only benefits your type-demotion optimization, and IMO its biggest advantage is the improvement to mem-op's bandwidth. Given those two parts are not quite related, is it better to split them and check them in separately?</div><div><br></div><div>I also found that after VF is increased according to the smallest type in the loop, at least on X86 both the cost model and the instruction combiner need to be adjusted and optimized accordingly, which is what I am working on.</div><div><br></div><div><br></div><div>Cong</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Cheers,</div><div><br></div><div>James</div></div><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Wed, 23 Sep 2015 at 12:51 <a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a> via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">hfinkel added a comment.<br>
<br>
Have you run LLVM's test suite with this turned on? Are there any significant performance changes? [I'm happy for this to go in, given that it's disabled by default, even if there are regressions to fix, but I'd like to know where we stand].<br>
<br>
.<br>
<br>
<br>
================<br>
Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:4585<br>
@@ +4584,3 @@<br>
+    // Collect all viable vectorization factors.<br>
+    SmallVector<unsigned, 4> VFs;<br>
+    unsigned NewMaxVectorSize = WidestRegister / SmallestType;<br>
----------------<br>
I'd make this 8 instead of 4 (we might have 7 VF for 8-bit integers in AVX-512, for example).<br>
<br>
<br>
<a href="http://reviews.llvm.org/D8943" rel="noreferrer" target="_blank">http://reviews.llvm.org/D8943</a><br>
<br>
<br>
<br></div></div>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</blockquote></div>
</blockquote></div><br></div></div>