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

Sanjoy Das via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 29 11:08:28 PST 2016

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

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

> 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
g = 0

which LLVM optimized to

g = 0


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

More information about the llvm-dev mailing list