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 | acb2fcdf24733549e411315d390b4320ab75a217 (patch) | |
| tree | d0a07be7366082e21467597e391ac1cd82ce10b3 /compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp | |
| parent | 0c6f946b82d2a2d988a8fd3d2336fac1b36d3174 (diff) | |
| parent | dbbfb6e08bfa9de32071d0bc20729a7b18e04202 (diff) | |
| download | rust-acb2fcdf24733549e411315d390b4320ab75a217.tar.gz rust-acb2fcdf24733549e411315d390b4320ab75a217.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_llvm/llvm-wrapper/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions