commit 801356fa200419eaa0626db52dc7511494ae9038
author bjacob <benoitjacob@google.com> Sun Sep 10 20:58:26 2023 -0400
committer GitHub <noreply@github.com> Sun Sep 10 20:58:26 2023 -0400
tree 65bd6ff0022ae0deda19f8975ead6cf2c14bc90f
parent 0eb7b1ad5b169946b0ca8c7410f819f1342887a2

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.