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

[Gil Rapaport via llvm-commits]

gilr added a comment.

Hi Michael,

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

> On the other hand, my worry is that long-term, as this kind of thing accumulates, we may end up with an ad-hoc "organically grown" mini-optimizer inside the vectorizer. And I'd really like to try to avoid that.


So this is a constant dilemma (e.g. in D21620 <https://reviews.llvm.org/D21620>). It's not just the question of whether a later pass will optimize but also of how to cost-model later hypothetical optimizations. I agree there's a slippery slope here, so we need to estimate the ROI per case.
I think this patch still falls under the "Generate no junk knowingly" category. Letting a later pass perform the actual sinking won't save us from performing the analysis in favor of the cost model's accuracy. The implementation is focused on the predicated instructions and is encapsulated in a single function, so it doesn't clutter the code (hope this will also hold for cost-model changes). I say Aye for this one.

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

> The fact this sinking patch requires https://reviews.llvm.org/D25631 to perform DCE inside the vectorizer only reinforces that concern.


Since https://reviews.llvm.org/D25631 fixes a somewhat sloppy behavior of the vectorizer I think it also falls under "Generate no junk knowingly", so it could stand on its own as part of the vectorizer's induction variable handling logic.


https://reviews.llvm.org/D25632