There are 2 parts to this patch, but I think they need to be simultaneous to avoid a regression.
- I'm proposing to reverse the canonicalization that moves bitwise vector ops before bitcasts. I want to move bitwise vector ops *after* bitcasts instead. That's the 1st and 3rd hunks of the patch. The motivation is that I only know of one fold that currently depends on the existing canonicalization (see next), but there are many folds that would automatically benefit from the new canonicalization. PR33138 ( https://bugs.llvm.org/show_bug.cgi?id=33138 ) shows why/how we have these patterns in IR.
- There's an or(and,andn) pattern that requires an adjustment in order to continue matching to 'select' because the bitcast changes position. This match is unfortunately complicated because it requires 4 logic ops with optional bitcast and sext ops. As part of making that part less ugly, I'd like to add a 'peekThroughBitcasts()' helper based on similar functions that we use in the DAG. (I can add that in a separate NFC commit if preferred.)
Test diffs:
- The bitcast.ll and bitcast-bigendian.ll changes show the most basic difference - bitcast comes before logic.
- There are also tests with no diffs in bitcast.ll that verify that we're still doing folds that were enabled by the previous canonicalization.
- icmp-xor-signbit.ll shows the payoff. We don't need to adjust existing icmp patterns to look through bitcasts.
- logical-select.ll contains several tests for the or(and,andn) --> select fold to verify that we are still handling those cases. The lone diff shows the movement of the bitcast from the new canonicalization rule.