[PATCH] D29489: Optimize SETCC + VSEL of incompatible or illegal types

[Jonas Paulsson via Phabricator via llvm-commits]

jonpa added a comment.

Eli, are you saying you think it is the right thing to handle these cases "after the fact" in ComputeNumSignBits(), as opposed to avoiding this per the previous version of the patch? I first wanted to check your opinion on this, since you earlier wanted things done early when you said we shouldn't handle scalarized code and then vectorize it again.

There is a bit more work in ComputeNumSignBits() to handle these nodes. Would the patch(es) of this function be useful regardless of how we handle VSELECT..?



================
Comment at: lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp:2835
+
+  if (N->getOpcode() != ISD::VSELECT || Cond->getOpcode() != ISD::SETCC)
+    return SDValue();
----------------
efriedma wrote:
> Have you tried simplifying the handling of Cond using WidenTargetBoolean?
Calling WidenTargetBoolean() instead of making a new SETCC results in a CONCAT_VECTORS and SIGN_EXTEND nodes of the original SETCC. This is not good, because the SIGN_EXTEND never disappears.

WidenTargetBoolean() and PromoteTargetBoolean() seem to have as the only behavior to extend the boolean vectors, which doesn't get folded properly by the SystemZ backend. It works very well for SystemZ to assume here that the VSELECT will be lowered to an instruction which produces a bitmask of the same type as its operands, but I guess this may be SystemZ specific, so would it be better to match the SIGN_EXTEND->SETCC in the SystemZ backend rather than trying to avoid it during type legalization?


https://reviews.llvm.org/D29489