<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Michael Kuperstein" <mkuper@google.com><br><b>To: </b>reviews+D27690+public+134fce31590ae349@reviews.llvm.org<br><b>Cc: </b>"Gil Rapaport" <gil.rapaport@intel.com>, "Matthew Simpson" <mssimpso@codeaurora.org>, "Hal Finkel" <hfinkel@anl.gov>, "Mikhail Zolotukhin" <mzolotukhin@apple.com>, "llvm-commits" <llvm-commits@lists.llvm.org><br><b>Sent: </b>Tuesday, December 13, 2016 1:17:42 PM<br><b>Subject: </b>Re: [PATCH] D27690: [LV] Don't vectorize when we have a static bound on trip count<br><br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><span class="gmail-"><br>
> b) Remainder loops for hand-vectorized code. These will also not be unrolled - the trip-count is unknown, and doesn't have a known multiple. (We may end up with runtime unrolling and yet another "remainder loop", which doesn't really improve things.) And, of course, it's almost always a bad idea to vectorize these. (The exception may be something like hand-vectorization by 16, with a scalar remainder loop. We may want to vectorize that remainder by 4 and leave a smaller scalar remainder, but that sounds like a very small win.)<br>
<br>
</span>I agree, but I think we're going about this the wrong way. The cost of the branching and runtime checks need to be factored into the cost model (which will be relevant for low-trip-count loops), and that should naturally prevent this kind of messiness. Just not vectorizing low-trip-count loops is suboptimial because it will miss cases where vectorization is quite profitable.<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br></div></div></blockquote><div><br></div><div id="DWT26079">You're completely right, but this isn't new - it's just that it's being applied non-uniformly, depending on what exactly we know about the trip count. That is, we do it "the wrong way" for loops with a known exact trip count, and don't do it at all with loop with a known upper bound.</div></div></div></div></blockquote>I apologize if I implied that this was a new problem being introduced by this patch. I certainly agree that it is not new.<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div id="DWT26080">I want us to start treating all three cases (static exact, static bound, dynamic) in the same way, by using the "right" number for the trip-count. Using this number in a smarter way (by estimating the overhead cost, and then dividing it by the trip-count to get the per-iteration cost*) is, I think, orthogonal to actually getting the number right.</div></div></div></div></blockquote>So long as that's the plan, then I'm fine with this. I agree that the uniformity is desirable, at least for now. There is still a difference in modeling the exact case vs. the unknown case, however, because the unknown case has a remainder loop and, thus, at least an extra compare/branch somewhere. I assume we'll want to account for this in the cost modeling.<br><br> -Hal<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div>* Well, almost. For a loop with 7 iterations that we vectorize by 4, we aren't really spreading the cost among "1.75" vectorized iterations, but just the one. This is negligible for high trip counts, but the whole point is to evaluate it correctly for the low case.</div></div></div></div>
</blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Lead, Compiler Technology and Programming Languages<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>