[PATCH] D70298: [LV] Avoid considering scalar-with-predication instructions as also uniform-after-vectorization, fix PR40816

Sun Dec 1 15:08:58 PST 2019

Ayal added a comment.

In D70298#1763255 <https://reviews.llvm.org/D70298#1763255>, @fhahn wrote:

> In the test case we predicate due to low trip count right? It might be worth calling that out.

Right, sure, called out.

> Also, it would be great if the test could be simplified a bit more (e.g. make the phi and related values i16, get rid of the truncation and the multiply). It seems like the test is not the most robust, as the load feeding the compare is not used at all after vectorisation, but I’m not sure if there’s another easy way to mark it as uniform at the moment.

Test has been simplified.
Long version: if the phi is turned into an i16, LV can no longer vectorize the loop even if forced, because LoopVectorizationLegality's convertPointerToIntegerType() prevents it (and thus any induction) from being a Primary Induction. So to simplify and get rid of the truncation while still vectorizing with fold-tail, all i16's are turned into i32's instead. To make sure the load is scalarized with predication, instead of forming an interleave group (once we get rid of the multiply) or a masked gather, the target is changed from knl to core-2. If a load feeding the latch-compare (thereby becoming Uniform-After-Vectorization) is live, the loop would probably not have a countable trip count, i.e., vectorizable. The other option for a load to become UAV is if it feeds a GEP known to be consecutive, or strided; but for that the load must be known to produce an arithmetic progression...

> LGTM thanks, any test improvements would be a nice bonus :) I agree that in most cases it’s unlikely that replicating a few uniform instructions will have a big impact.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70298/new/

https://reviews.llvm.org/D70298