- User Since
- May 5 2014, 7:26 AM (297 w, 6 d)
Sat, Jan 18
You might be able to fix it with the equivalent of rG80146fc13ada
Cheers Craig, TBH I'm left wondering whether we should tweak the update script to always keep stack arithmetic for x86 - do you think they'd be too much churn?
@epastor This is causing build bots failures, please can you take a look? http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l/builds/3121
Fri, Jan 17
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.
Thu, Jan 16
@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?
@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