| Issue |
120837
|
| Summary |
No good way to express atomicrmw on pointers
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
RalfJung
|
In Rust, we'd like to add atomic RMW operations on pointers. For instance, we have an atomic fetch_add that is supposed to behave like a version of `getelementptr` that atomically adjusts an in-memory pointer. However, when generating LLVM IR we currently have to do the `atomicrmw` at type `i64`. This has multiple problems:
- It requires casting the pointer argument to an integer, which is an operation with non-trivial consequences (the pointee is irrevocably "exposed" by this).
- Worse, it acts on a pointer stored in-memory as if it was an integer. The consequences of this for pointer provenance (the concept of which pointer is "derived from" which other pointer) are unclear, but naive answers are known to be wrong (if you are curious about this, I wrote a [series](https://www.ralfj.de/blog/2020/12/14/provenance.html) of [blog posts](https://www.ralfj.de/blog/2022/04/11/provenance-exposed.html) on the subject a while ago)
- It can't really work on CHERI (not even after using the proper size, `i64`), where pointers and integers are decidedly different objects (not sure if CHERI has special instructions to atomically update pointers; if not, this would have to be lowered to a CAS loop)
It would be great if LLVM had a way to directly represent the desired semantics here: an `atomicrmw add`, or instance, that takes an integer argument but is specified to treat the memory contents as a pointer, performing `getelementptr`-style arithmetic on it, and returns something of type `ptr`. Bitwise operations wold also make sense, they would behave like `ptrmask`. That avoids any ambiguities around provenance / which pointer is "derived from" which other pointer.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
