We don't have any combines that can look through a bitcast to truncate a build vector of constants. So the truncate will stick around and give us something like this pattern (binop (trunc X), (trunc (bitcast (build_vector)))) which has two truncates in it. Which will be reversed by hoistLogicOpWithSameOpcodeHands in the generic DAG combiner. Thus causing an infinite loop.
Even if we had a combine for (truncate (bitcast (build_vector))), I think it would need to be implemented in getNode otherwise DAG combiner visit ordering would probably still visit the binop first and reverse it. Or combineTruncatedArithmetic would need to do its own constant folding.
This came to me as infinite loop a colleague found with ISPC. In his case the bitcast got introduced after type legalization do it being a v4i64 build_vector on a 32-bit target. But that also means you need to have delayed combineTruncatedArithmetic seeing the constant until after type legalization. So my early attempts at a simple test case have failed. I'll keep at it.
Please add to this comment to make it explicit that we're not peeking through bitcast to avoid fighting with another transform.