-
Notifications
You must be signed in to change notification settings - Fork 608
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Un-unroll ukernel C+intrinsics code. (#14908)
Fully unrolling C+intrinsics code is a common defensive practice vs. the tendency of compilers to miss good codegen of SIMD code. It's not just about the loops, it's about using arrays of vector-variables, which is necessary to be able to write loop. A sufficiently naive compiler will literally take that to mean that the vectors are memory objects. Several years ago I had filed https://bugs.llvm.org/show_bug.cgi?id=34945 and never heard back about it. To this day, XNNPACK sticks to this practice, e.g. https://github.com/google/XNNPACK/blob/master/src/f32-gemm/gen/f32-gemm-8x8s4-minmax-neon.c#L238-L269 . This prompts the question of how to manage the resulting verbose code, how to scale to supporting many variants of ukernels. The immediate motivation for us here is as we are about to introduce narrow variants of matmul kernels. XNNPACK deals with that with a Python-based generator of unrolled C code. In our case, as our primary deployment path for ukernels is to compile them to LLVM bitcode that IREE can then inline at each call site and "LTO", where it should be able to perform loop unrolling and dead code optimization, it would be neat to simply take advantage of that, instead of inventing a new way to unroll loops and skip over dead code, or carry verbose source code. The danger is regressing performance in the native-toolchain, non-bitcode builds of ukernels. That's only used in VMVX, and in ukernel's own micro benchmarks (and unit tests). Performance of that isn't really critical. We want to make sure that we build correctly there, but it's OK to have suboptimal performance. To be clear, to preserve performance in the native build, we will still instantiate functions with the loop size known at compile time (calling into the shared loop impl, inlined into each case). The only question is whether the native toolchain will handle that inlining as well as Clang does. Concretely, I tried one case, and found that GCC generates ~ 2x slower code, while Clang and MSVC did fine. https://godbolt.org/z/WsbW487ze Just look at the code shrink here. And this is only a first step. As a next PR will introduce variants for narrow M0 dimensions, they will be able to all share the same loop implementation, both in source code and in embedded bitcode in the bitcode build.
- Loading branch information
Showing
9 changed files
with
490 additions
and
1,348 deletions.
There are no files selected for viewing
337 changes: 99 additions & 238 deletions
337
runtime/src/iree/builtins/ukernel/arch/arm_64/mmt4d_arm_64.c
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.