Is there a bz for this?
LGTM - I don't have a problem with keeping PromoteMaskArithmetic tbh
LGTM - technically this is a limited version of a "lowerShuffleAsLanePermuteAndUNPCK" pattern that we might want to investigate in the future, but its a more controllable initial implementation.
@khchen We have a load of EXPENSIVE_CHECKS RISCV MC + asm failures, a lot of which appear to be related to these changes to RISCVAsmParser please can you take a look?
I'm trying to figure that out, the change is supposed to be off by default except the added test case and shouldn't affect anyone functionally.
What's LLVM policy in such cases - revert?
@ashlykov This is failing on EXPENSIVE_CHECKS builds - revert? http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-debian/builds/1493/
Wed, Jan 15
reverted due to EXPENSIVE_CHECKS fails: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-ubuntu/builds/1917
This is causing EXPENSIVE_CHECKS failures - revert this? http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-ubuntu/builds/1917
Tue, Jan 14
OK - LGTM
TBH I don't think this is worth it unless you can demonstrate actual reductions in compile time - once C++20 lands and we're allowed to use its features we can move to using std::popcount and avoid all of this.
Mon, Jan 13
Sun, Jan 12
I haven't looked at v8f32 shuffles yet (only the cases that widen to v4f64 get handled) - but I've just added binary v4f64 support in rG66e39067edbf
Sat, Jan 11
Fri, Jan 10
Not sure if its reusable but we already have signExtendBitcastSrcVector which we use for the (i16 bitcast (v16i1 x)) combine