-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wasm32-unknown-unknown "C" ABI doesn't use proper ABI adjustments #115666
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
…exception, r=workingjubilee,RalfJung NVPTX: Allow PassMode::Direct for ptx kernels for now Upgrading the nvptx toolchain to the newest nightly makes it hit the assert that links to rust-lang#115666 It seems like most targets get around this by using `PassMode::Indirect`. That is impossible for the kernel as it's not a normal call, but instead the arguments are copied from CPU to GPU and the passed pointer would be invalid when it reached the GPU. I also made an experiment with `PassMode::Cast` but at least the most simple version of this broke the assembly API tests. I added fixing the pass mode in my unofficial tracking issue list (I do not have the necessary permissions to update to official one). rust-lang#38788 (comment) Since the ptx_abi is currently unstable and have been working with `PassMode::Direct` for more than a year now, the steps above is hopefully sufficient to enable it as an exception until I can prioritize to fix it. I'm currently looking at steps to enable the CI for nvptx64 again and would prefer to finish that first.
Rollup merge of rust-lang#117247 - kjetilkjeka:nvptx_direct_passmode_exception, r=workingjubilee,RalfJung NVPTX: Allow PassMode::Direct for ptx kernels for now Upgrading the nvptx toolchain to the newest nightly makes it hit the assert that links to rust-lang#115666 It seems like most targets get around this by using `PassMode::Indirect`. That is impossible for the kernel as it's not a normal call, but instead the arguments are copied from CPU to GPU and the passed pointer would be invalid when it reached the GPU. I also made an experiment with `PassMode::Cast` but at least the most simple version of this broke the assembly API tests. I added fixing the pass mode in my unofficial tracking issue list (I do not have the necessary permissions to update to official one). rust-lang#38788 (comment) Since the ptx_abi is currently unstable and have been working with `PassMode::Direct` for more than a year now, the steps above is hopefully sufficient to enable it as an exception until I can prioritize to fix it. I'm currently looking at steps to enable the CI for nvptx64 again and would prefer to finish that first.
…, r=workingjubilee,RalfJung NVPTX: Allow PassMode::Direct for ptx kernels for now Upgrading the nvptx toolchain to the newest nightly makes it hit the assert that links to rust-lang/rust#115666 It seems like most targets get around this by using `PassMode::Indirect`. That is impossible for the kernel as it's not a normal call, but instead the arguments are copied from CPU to GPU and the passed pointer would be invalid when it reached the GPU. I also made an experiment with `PassMode::Cast` but at least the most simple version of this broke the assembly API tests. I added fixing the pass mode in my unofficial tracking issue list (I do not have the necessary permissions to update to official one). rust-lang/rust#38788 (comment) Since the ptx_abi is currently unstable and have been working with `PassMode::Direct` for more than a year now, the steps above is hopefully sufficient to enable it as an exception until I can prioritize to fix it. I'm currently looking at steps to enable the CI for nvptx64 again and would prefer to finish that first.
FWIW, |
Hm yeah that's not great, though it might be related to #117271 given both are about GPUs. |
I'm reviewing the change @LegNeato mentioned and ended up here semi-randomly, so I might as well answer this: Rust-GPU only started using
So it probably makes most sense to turn And while writing this comment I went ahead and tried it and the only issues stem from lacking extra logic to handle the indirect case in a few places (mainly the |
wasm-bindgen 0.2.62 is not compatible with a wasm ABI change that rustc wishes to enable by default for wasm32-unknown-unknown, currently gated behind passing the -Zwasm-c-abi flag to rustc. wasm-bindgen 0.2.89 should exhibit seamless behavior before and after the ABI change to match the C ABI, so depend on that. For more information, see - rust-lang/rust#115666 - rust-lang/rust#117918 - rust-lang/rust#122532
rustc has a
PassMode
enum to declare how arguments should be passed between functions.PassMode::Direct
is used for the simple case where we can just generate LLVM IR with an argument type that matches the usual LLVM type for this Rust type. It should only be used for types withScalar
orVector
ABI; for larger types, Rust will generate LLVM struct/union types and thoserepr(transparent)
types.Unfortunately the compiler never had an assertion ensuring that
PassMode::Direct
is only used withScalar
/Vector
types, and so one target accidentally broke this rule: wasm32-unknown-unknown. Later all wasm targets got anextern "wasm"
ABI that has the same issue. We should find some way to fix this target, as the current situation makes life harder for anyone wanting to tweak our Rust-to-LLVM-type-mapping, and for alternative backends that have to match our effective ABI.The issue is that last time @bjorn3 tried to fix this, it lead to #81386 and had to be reverted. It will be basically impossible to do this change without breaking the ABI at least for some cases. I'm not sure how much ABI breakage we can get away with. This might have to be blocked on rust-lang/compiler-team#672 which should help to implement the current effective ABI at least for types that are ABI-stable (i.e.,
repr(C)
andrepr(transparent)
).Cc #122532
The text was updated successfully, but these errors were encountered: