Cherry-pick some changes for SIMD and WebAssembly #96
Conversation
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
As proposed in WebAssembly/simd#395 and matching the opcodes used in V8: https://chromium-review.googlesource.com/c/v8/v8/+/2617385/4/src/wasm/wasm-opcodes.h Differential Revision: https://reviews.llvm.org/D95557
Now that the WebAssembly SIMD specification is finalized and engines are generally up-to-date, there is no need for a separate target feature for gating SIMD instructions that engines have not implemented. With this change, v128.const is now enabled by default with the simd128 target feature. Differential Revision: https://reviews.llvm.org/D98457
Removes the instruction definitions, intrinsics, and builtins for qfma/qfms, signselect, and prefetch instructions, which were not included in the final WebAssembly SIMD spec. Depends on D98457. Differential Revision: https://reviews.llvm.org/D98466
Updates the names (e.g. widen => extend, saturate => sat) and opcodes of all SIMD instructions to match the finalized SIMD spec. Deliberately does not change the public interface in wasm_simd128.h yet; that will require more care. Depends on D98466. Differential Revision: https://reviews.llvm.org/D98676
|
I'm a bit concerned that this breaks bitcode compatibility with clang-12. Is cross-language LTO for wasm something we need to be concerned about or not? |
|
For the use case of cross-language LTO with Rust & C I think there's not much to be concerned about with the wasm target. I didn't think this would affect any other targets but if it does I can try to fix that! |
|
Okay, that's good enough for me... |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this pull request
Mar 18, 2021
This is a continuation of rust-lang/llvm-project#96 to continue to make progress on updating Rust's support for SIMD intrinsics on WebAssembly to the latest version of the specification.
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Mar 19, 2021
…viper Update LLVM to bring in SIMD updates for WebAssembly This is a continuation of rust-lang/llvm-project#96 to continue to make progress on updating Rust's support for SIMD intrinsics on WebAssembly to the latest version of the specification.
nikic
pushed a commit
that referenced
this pull request
May 8, 2021
This patch implemented TTI.IntImmCost() properly. Each BPF insn has 32bit immediate space, so for any immediate which can be represented as 32bit signed int, the cost is technically free. If an int cannot be presented as a 32bit signed int, a ld_imm64 instruction is needed and a TCC_Basic is returned. This change is motivated when we observed that several bpf selftests failed with latest llvm trunk, e.g., #10/16 strobemeta.o:FAIL #10/17 strobemeta_nounroll1.o:FAIL #10/18 strobemeta_nounroll2.o:FAIL #10/19 strobemeta_subprogs.o:FAIL #96 snprintf_btf:FAIL The reason of the failure is due to that SpeculateAroundPHIsPass did aggressive transformation which alters control flow for which currently verifer cannot handle well. In llvm12, SpeculateAroundPHIsPass is not called. SpeculateAroundPHIsPass relied on TTI.getIntImmCost() and TTI.getIntImmCostInst() for profitability analysis. This patch implemented TTI.getIntImmCost() properly for BPF backend which also prevented transformation which caused the above test failures. Differential Revision: https://reviews.llvm.org/D96448 (cherry picked from commit a260ae7)
vext01
added a commit
to vext01/llvm-project
that referenced
this pull request
Oct 19, 2023
96: Kill debugging. r=ltratt a=vext01 Co-authored-by: Edd Barrett <vext01@gmail.com>
nikic
pushed a commit
to nikic/llvm-project
that referenced
this pull request
Dec 21, 2023
This PR adds support for thread names in lldb on Windows. ``` (lldb) thr list Process 2960 stopped thread rust-lang#53: tid = 0x03a0, 0x00007ff84582db34 ntdll.dll`NtWaitForMultipleObjects + 20 thread rust-lang#29: tid = 0x04ec, 0x00007ff845830a14 ntdll.dll`NtWaitForAlertByThreadId + 20, name = 'SPUW.6' thread rust-lang#89: tid = 0x057c, 0x00007ff845830a14 ntdll.dll`NtWaitForAlertByThreadId + 20, name = 'PPU[0x1000019] physics[main]' thread rust-lang#3: tid = 0x0648, 0x00007ff843c2cafe combase.dll`InternalDoATClassCreate + 39518 thread rust-lang#93: tid = 0x0688, 0x00007ff845830a14 ntdll.dll`NtWaitForAlertByThreadId + 20, name = 'PPU[0x100501d] uMovie::StreamingThread' thread #1: tid = 0x087c, 0x00007ff842e7a104 win32u.dll`NtUserMsgWaitForMultipleObjectsEx + 20 thread rust-lang#96: tid = 0x0890, 0x00007ff845830a14 ntdll.dll`NtWaitForAlertByThreadId + 20, name = 'PPU[0x1002020] HLE Video Decoder' <...> ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pulls in some changes recently landed upstream for WebAssembly which update opcodes and tweak a few internals about how simd is handled. This is in preparation for the recently-stabilized simd proposal to update the stdarch repo with more intrinsics.
I've tested this locally and it enables a whole slew of new intrinsics, although there will likely be another future cherry-pick or two since there's still some instructions that LLVM doesn't fully support just yet.