WebAssembly: Autovectorization Fails In Loops

When working with WebAssembly and aiming for optimized SIMD (Single Instruction, Multiple Data) performance, autovectorization plays a crucial role. This article delves into a peculiar issue encountered when compiling C code with clang for WebAssembly using the -Os -msimd128 flags. Specifically, we'll explore why autovectorization to v128.bitselect sometimes fails within loops, while succeeding in unrolled function implementations.

The Autovectorization Anomaly

The core of the problem lies in the inconsistent behavior of clang's autovectorizer. When a function designed to mimic SIMD operations is written in an unrolled fashion, it often autovectorizes correctly to the desired v128.bitselect instruction. However, when the same logic is implemented using a loop, the autovectorizer may fall back to scalar operations on i64 lanes, leading to suboptimal performance. This discrepancy raises questions about the conditions under which clang's autovectorizer makes its decisions.

Let's illustrate this with code examples. Consider the following function, opFD52_v128_bitselect, which performs a bitwise selection operation on 128-bit vectors:

static inline v128_t opFD52_v128_bitselect(v128_t a, v128_t b, v128_t c)
{
    a.u64[0] = a.u64[0] & c.u64[0] | b.u64[0] & ~c.u64[0];
    a.u64[1] = a.u64[1] & c.u64[1] | b.u64[1] & ~c.u64[1];
    return a;
}

In this unrolled version, clang typically autovectorizes the code to utilize the v128.bitselect instruction, which is highly efficient for SIMD operations. This is the desired outcome, as it leverages the full potential of the 128-bit vector processing capabilities.

Now, let's examine the equivalent function implemented using a loop:

static inline v128_t opFD52_v128_bitselect(v128_t a, v128_t b, v128_t c)
{
    for (int i=0; i<2; i++)
        a.u64[i] = a.u64[i] & c.u64[i] | b.u64[i] & ~c.u64[i];
    return a;
}

In this looped version, the autovectorizer often fails to recognize the opportunity for v128.bitselect and instead resorts to scalar operations on i64 lanes. This results in significantly lower performance, as the code is not taking advantage of the available SIMD instructions. The inconsistency between the two versions is perplexing and warrants further investigation.

Potential Causes and Investigations

Several factors could contribute to this autovectorization anomaly. One possibility is that the loop structure hinders the compiler's ability to recognize the underlying SIMD pattern. The loop introduces dependencies and control flow that might obscure the opportunity for vectorization.

Another potential factor could be the optimization level. While -Os aims for size optimization, it might inadvertently disable certain vectorization passes that are crucial for recognizing the v128.bitselect pattern within loops. It's worth experimenting with different optimization levels, such as -O3, to see if it resolves the issue.

Furthermore, the specific version of clang being used could also play a role. Compiler bugs and limitations can sometimes affect autovectorization behavior. It's advisable to try different clang versions to determine if the issue is specific to a particular release.

To further investigate this issue, one could examine the LLVM intermediate representation (IR) generated by clang for both the unrolled and looped versions of the function. By comparing the IR, it might be possible to pinpoint the exact point at which the autovectorization process diverges.

Strategies for Achieving Autovectorization

Despite the challenges, there are several strategies one can employ to encourage autovectorization in loop-based code.

1. Loop Unrolling

While the original goal was to avoid manual unrolling, sometimes it's the most reliable solution. If the loop count is small and known at compile time, manually unrolling the loop can expose the SIMD pattern more clearly to the compiler. This approach essentially transforms the loop-based code into the unrolled version that already works.

2. Compiler Hints and Pragmas

Clang provides several compiler hints and pragmas that can influence the autovectorization process. For example, the #pragma clang loop vectorize(enable) directive can explicitly instruct the compiler to attempt vectorization of a specific loop. However, these hints are not always effective, and the compiler may still choose not to vectorize the loop for various reasons.

3. Code Restructuring

Sometimes, simply restructuring the code can make it more amenable to autovectorization. This might involve rearranging the loop body, introducing temporary variables, or using different data access patterns. The key is to present the code in a way that makes the SIMD pattern more apparent to the compiler.

4. Explicit SIMD Intrinsics

If autovectorization proves too unreliable, one can resort to using explicit SIMD intrinsics. These are special functions provided by the compiler that directly map to specific SIMD instructions. While this approach requires more manual effort, it provides the most control over the generated code and ensures that the desired SIMD instructions are used.

Conclusion

The autovectorization anomaly observed with v128.bitselect in WebAssembly highlights the complexities of compiler optimization. While clang can successfully autovectorize unrolled code, it sometimes struggles with equivalent loop-based implementations. Understanding the potential causes of this issue and employing appropriate strategies can help developers achieve optimal SIMD performance in their WebAssembly applications.

Further research and experimentation are needed to fully understand the conditions under which clang's autovectorizer makes its decisions. By gaining a deeper understanding of the autovectorization process, developers can write more effective code that leverages the full potential of WebAssembly's SIMD capabilities.

For more in-depth information on WebAssembly and SIMD, you can visit the WebAssembly official website.