I set the operation actions for VSELECT of appropriate vector types to be
Custom, and am taking care that the ones that were Legal are still treated
as that after the Custom step. Same goes for the ones previously marked as
Expand.
LowerVSELECT will, if possible, generate a X86ISD::BLENDI DAG node if the
condition is constant and we can emit that instruction, given the
subtarget.
This is not enough for all cases. If we're doing a vselect on vectors that
are not legal on this target they will be split. The best option I could
find, and which implies less code (and bugs) was to add a case to
PerformSELECTCombine, in order to match this operand split (we add some
size extensions when we legalize the types).
I also updated all the tests that failed because they were expecting
variable byte blends (blendvb) or similar and they had a vector of
constant conditions.
This function could be simplified a bit if
BuildVector is known to always be a build_vector dag node of all ConstantSDNode (or UNDEF) elements.
I think you can easily add it as a precondition; the caller can verify if a node is a build_vector of constants (or undef values) by simply calling function
ISD::isBuildVectorOfConstantSDNodes.
Also, given that argument 'BuildVector' can only be a build_vector dag node, you can change the signature of this function to something like:
This is to make explicit that BuildVector can only be a BuildVectorSDNode.
Under the assumption that BuildVector is a build_vector of constants or UNDEFs, then
lines in the range [7992-8008] can be simplified and replaced by the folling 5 lines.
The function will return false only if Lane1Cond != Lane2Cond && Lane1Cond and Lane2Cond both are >= 0.