[llvm] [LangRef] Specify that dereferenceable implies a spurious read (PR #218413)
Ralf Jung via llvm-commits
llvm-commits at lists.llvm.org
Sat Aug 29 23:46:56 PDT 2026
RalfJung wrote:
> Re: retroactive reads of poison, my current mental model for this sort of retroactive change in multithreaded programs is that accesses that might potentially race can nondeterministically return poison, but any such execution that subsequently turns out not to lead to another thread racing on the address is "non-behavior" (i.e. the program has to be compiled in such a way that such executions cannot happen).
That definition makes almost all code out there UB. So it's not even remotely practical.
> On a separate note, an observation on the consequences of the change proposed in this PR (dereferenceable permitting a spurious read that conflicts with noalias) is that it becomes extremely hard to infer dereferenceable later in a function based on a dereferenceable at entry.
That's exactly what the discussion above was about.
https://github.com/llvm/llvm-project/pull/218413
More information about the llvm-commits
mailing list