[PATCH] D25632: [LV] Sink scalar operands of predicated instructions

[Matthew Simpson via llvm-commits]

mssimpso added a comment.

In https://reviews.llvm.org/D25632#570824, @mkuper wrote:

> Why do this inside the vectorizer? Are we missing a later code sinking pass?


Hi Michael,

We actually do have an IR sinking pass (Transforms/Scalar/Sink.cpp), but it's not in the current pass pipeline. I've experimented with it in the past and observed some fairly large performance regressions when using it. It doesn't seem like the compiler is tuned for an "always sink where possible" pass. The sinking implemented in this patch is only aimed at the operands of the predicated instructions. It's really an extension of Gil's work for predicated instructions and all the scalarization we do now. We were previously only sinking the extractelement instructions we created when predicating, but we can do more.

The end goal is to get us closer to preserving the membership of the original predicated blocks if profitable, rather than always vectorizing and hoisting the instructions through if-conversion (aside from the stores, divs, and rems we can't vectorize). So we will need access to the cost model. The current patch sinks all the existing scalar operands, but the cost model may deem it more profitable for us to scalarize an instruction we otherwise would have vectorized, knowing that it is guaranteed to be sunk into a predicated block. I have a follow-on patch that does this.

With that in mind, my thoughts are that in the vectorizer, we (1) know the state of the program before and and after if-conversion. (i.e., was this instruction originally conditionally executed? If so, it might be good to leave it that way. Not, this instruction isn't need on all paths, so let's always sink it). And (2), we at least have some way to judge the profitability of this kind of decision.

Hope that helps (and makes sense)!


https://reviews.llvm.org/D25632