[PATCH] D53612: [LV] Avoid vectorizing loops under opt for size that involve SCEV checks

Hideki Saito via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 25 11:04:59 PDT 2018


hsaito added a comment.

In https://reviews.llvm.org/D53612#1275437, @bjope wrote:

> The patch will avoid the assert seen in PR39417 so that is great.
>  (hard to tell if it still is possible to hit the assert, PR39417 was triggered during fuzzy testing using csmith to generate the input)
>
> One thing I noticed is that if I use the test case from PR39417 and add `-vectorizer-min-trip-count=3`, to avoid the detection of a "very small trip count", the loop will be vectorized with VF=16. That is also what happened when we triggered the assert (without this patch). Shouldn't the VF be clamped to the trip count? 
>  It seems like the vectorizer detects that the trip count is tiny (trip count is 3), but it vectorize using VF=16 but then the vectorized loop is skipped since we emit `  br i1 true, label %scalar.ph, label %vector.scevcheck`. So all the hard work with vectorizing the loop is just a waste of time, or could it be beneficial to have `VF > tripcount` in some cases?
>
> If the actual problem is that VF should be clamped to the trip count, then maybe this patch just hides that problem in certain cases (when having OptForSize).


VF doesn't have to be clamped to tripcount, but it should be clamped to reasonable multiple of natural vector size (e.g., executing 3-iter loop using 4-way vector could be better than 2-way vector if 2-way vector is less than full vector)--- and we need to ensure we'll hit vector code if vectorizer intentionally used VF that is greater than constant tripcount. Please file a separate ticket.


Repository:
  rL LLVM

https://reviews.llvm.org/D53612





More information about the llvm-commits mailing list