rust
/
rfcs
mirror of https://github.com/rust-lang/rfcs
1
0
Fork 0
Code Issues Releases Wiki Activity

improve wording

This commit is contained in:
Ralf Jung 2024-01-25 18:20:45 +01:00
parent 1b7e1bc8fd
commit 2c7624634a
1 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
text/0000-rust-has-provenance.md
View File

@ -215,14 +215,15 @@ The biggest downside of provenance is complexity. The existence of provenance me
The other main drawback is the lack of proper treatment of provenance in LLVM, our primary codegen backend.
LLVM suffers from various long-standing provenance-related bugs ([[1]](https://github.com/llvm/llvm-project/issues/34577), [[2]](https://github.com/llvm/llvm-project/issues/33896)), and there is currently no concrete plan for how to resolve them.
The opinion of the RFC author is that LLVM needs to stop using pointer comparisons in GVN, and it needs to stop folding ptr2int2ptr cast roundtrips.
Those optimization cannot be justified with any form of provenance, and LLVM's alias analysis cannot be justified without some form of provenance.
Furthermore, LLVM needs to decide whether the `iN` type carries provenance or not.
To keep all the integer-related optimization, it is likely necessary to decide that it does *not* carry provenance.
To keep all the integer-related optimizations, it is likely necessary to decide that it does *not* carry provenance.
This would then necessitate the introduction of a "byte" type that *does* carry provenance, as without such a type it would be impossible to load and store individual bytes (or in general, anything but a ptr-sized chunk of memory) in a provenance-preserving manner.
(A byte type has been [proposed](https://lists.llvm.org/pipermail/llvm-dev/2021-June/151521.html), but so far the LLVM community has not been supportive of that proposal.)
(A byte type for LLVM has already been [proposed](https://lists.llvm.org/pipermail/llvm-dev/2021-June/151521.html) since it also solves other issues, but so far the LLVM community has not been supportive of that proposal.)
If that is what LLVM ends up deciding, it will be entirely compatible with this RFC.
If LLVM makes some different choice, that might be incompatible with Rust's choices.
However, given that there is no alternative proposal on the table for what LLVM could do, it's not possible to specify Rust in a way that is compatible with "whatever LLVM will do".
There has been no attempt from the side of the LLVM project to make progress on these questions (as far as the author is aware), so there are only two options: (a) wait until LLVM does something, and then do something compatible in Rust, or (b) do something that makes sense for Rust, and if eventually there is movement on the LLVM side, work with them to ensure Rust's needs are covered.
However, it's not possible to specify Rust in a way that is compatible with "whatever LLVM will do".
There has been no progress on these questions on the side of the LLVM project for many years (as far as the author is aware), and no concrete proposal aside from the one sketched above, so there are only two options: (a) wait until LLVM does something, and then do something compatible in Rust, or (b) do something that makes sense for Rust, and if eventually there is movement on the LLVM side, work with them to ensure Rust's needs are covered.
(a) means indefinitely blocking progress on pressing questions in the Rust semantics, so this RFC takes the position that we should do (b).
(To the author's knowledge, GCC is not in a better position, and it suffers from [similar bugs](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82282), so we can't use their semantics for guidance either.)