Addressed comments

In D91271#2497380, @mstorsjo wrote:

This broke compilation of some sources...

Addressed comments; modifying checks and updating tests.

In D94234#2484467, @fhahn wrote:

this needs a test?

In D91255#2484399, @dmajor wrote:

This commit caused a crash on our bots with a null LLVMTy at changeExtendedVectorElementType. Reduced case: https://godbolt.org/z/7ehffx

Made the return value respect whether any operands are to be sunk.

Addressed comments, updating the checks and tests

Added test case for non-splat shuffles

I can't see any issues with this, LGTM

Fixed incorrect error-handling

Addressed Comments

Addressed comments, and re-added a couple of "Unsupported combines" tests.

Fixed formatting, and removed "Unsupported combines" tests as they were failing due to a separate issue (and contribute very little value to this patch)

Fixed broken commit

Addressed comments, and rebased on top of the changes in the parent revision.

Fixed more formatting issues (that were apparently missed by clang-format before?)

Can you run clang-format on the patch to make it more readable?

Done, sorry about that (Guess I should have another look at my pre-commit hooks)

Removed redundant/useless debug prints that were erroneously included in the patch.

Addressed comments, and changed to be more targeted. The rearrangement will only be performed if the pattern feeds into a mul instruction, and only if the type combination is valid for smull/umull folding.

This looks like two separate patches to me.

This pattern isn't needed I don't think

I appreciate that the history and context for this has been a bit obscured. Most of it can be gathered on the patch D83667

I think a MIR test would be better here.

Looks nice to me. Is it worth adding mul (sext_inreg, sext i32) patterns too in case one operand is sext and the other is being masked? mul is commutative so I think it would only be two extra patterns, one for sext and one for zext.

Rebased atop changes to https://reviews.llvm.org/D88494

I'm a little concerned IfConversion isn't really prepared to deal with the distinction here: in some cases, if conversion doesn't predicate all the instructions in the if-converted block.

Do we really need the boolean to default to false? There are only two callers, as far as I can tell.

Looks like we've lost access to https://crbug.com/1114852, so can't access the build repro. Is this something you can sort out for us?

Hi @akhuang, thanks for bringing this up.

LGTM, if no one else has any issues.

Source changes look good to me, just a few test-related points to address.

Addressed comments, and rebased to include D84653 (Which handles the IT-block instruction legality)

Updates some comments. NFC when compared to prior diffs

Addressing inline comments

Reworded/improved summary, and included full patch context