diff options
| author | Matthias Krüger <476013+matthiaskrgr@users.noreply.github.com> | 2025-05-30 07:01:30 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-05-30 07:01:30 +0200 |
| commit | ad2d91ce11ccdad5af3b7eca3c29c72a4ed06f74 (patch) | |
| tree | fdc52aa385e763ddd3091173e71b7d422b844f78 /compiler/rustc_codegen_llvm/src/errors.rs | |
| parent | a87bc9d9fe52eb94ec47694c0bae3232e0bc6f02 (diff) | |
| parent | a387c86a929c27c102833c55bebad11cfc1c155d (diff) | |
| download | rust-ad2d91ce11ccdad5af3b7eca3c29c72a4ed06f74.tar.gz rust-ad2d91ce11ccdad5af3b7eca3c29c72a4ed06f74.zip | |
Rollup merge of #141507 - RalfJung:atomic-intrinsics, r=bjorn3
atomic_load intrinsic: use const generic parameter for ordering We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that! This PR only converts `load`, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics. The first two commits are preparation and could be a separate PR if you prefer. `@BoxyUwU` -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer... `@bjorn3` it seems like the cranelift backend entirely ignores the ordering?
Diffstat (limited to 'compiler/rustc_codegen_llvm/src/errors.rs')
0 files changed, 0 insertions, 0 deletions