[PATCH] D101684: [WebAssembly] Add end-to-end codegen tests for wasm_simd128.h

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun May 2 16:21:22 PDT 2021


dblaikie added a comment.

In D101684#2732522 <https://reviews.llvm.org/D101684#2732522>, @aheejin wrote:

> I think there's a clear upside on keeping this within clang/.
>
> 1. As @tlively said, there are many number of instructions to test and keeping "C function - LLVM intrinsic" and "LLVM intrinsic - Wasm instruction" tests in sync without autogeneration will be hard and error-prone.

I don't necessarily see that they should be kept in sync - in the same way that we don't do this for other IR targets and other features, like ABIs - it's important they are lowered to specific instructions, but we don't generally validate that through end to end tests.

> 2. Also it is not always the case that we have 1-1-1 relationship of C intrinsic function - LLVM intrinsic - Wasm instruction. For some of these we don't have our own intrinsics but rather use LLVM's common intrinsics, and they don't always boil down to a single LLVM intrinsic. There are cases where a single C function call can be lowered to multiple instructions in the LLVM IR, which we try to pattern match and lower to a single Wasm instruction. This kind of relationship can't be tested easily so it will take significantly longer time to check if a single C function call will result in a single Wasm instruction.

The lack of 1-to-1 is part of the reason I prefer these tests to be separate. If one C level intrinsic lowers to multiple IR operations - then it's good to test each of those IR operations separately from each other. So that all their uses can be validated. Then, knowing they are validated - the Clang C-to-IR test can test that suitable operations are generated, knowing that they're tested in LLVM to work as specified.

> It might be good to move this to clang/test/CodeGen though, if that's more suitable.

I'm still not following why this is different from existing testing - many targets already exist in LLVM and already test their intrinsics in various ways, generally, so far as I know (though I haven't looked comprehensively - might be worth you taking a look at existing test strategies for intrinsics to compare/contrast?) . Why is WebAssembly different here?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101684/new/

https://reviews.llvm.org/D101684



More information about the llvm-commits mailing list