[llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")

[Sanjoy Das via llvm-dev]

I may be misunderstanding you here, but I've tried to reply inline
below:

On Mon, Feb 29, 2016 at 11:00 AM, Xinliang David Li
<xinliangli at gmail.com> wrote:
> yes -- it is UB if user writes code like this.

So we agree that given that the user wrote exactly what you have
above, there is no guarantee from the compiler to generate anything
meaningful?

> What if the g=0 is
> speculatively moved above the call of maybe_divide at O2?  My point is that

You mean, the program was initially something like

g = 42
maybe_divide(&g)
g = 0

which LLVM optimized to

g = 0
maybe_divide(&g)

?

That code motion is legal only if `maybe_divide` is `readnone` -- if
LLVM speculates the store without first inferring `readnone` on
`maybe_divide`, that's buggy for a different reason.

> such runtime behavior difference may not specific to multi-TU definition
> scenario.

The multi-TU constraint is relevant here because the linker may
legally replace a `readnone` version of `maybe_divide` with version
that reads memory; retroactively invalidating the optimization above.  If
there is only one TU, then the `maybe_divide` the optimizer sees is
what the final executable gets; and all is well.

-- Sanjoy