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

[Xinliang David Li via llvm-dev]

On Mon, Feb 29, 2016 at 11:08 AM, Sanjoy Das <sanjoy at playingwithpointers.com
> wrote:

> 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?
>
>
yes.


> > 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.
>

right.


>
> > 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.
>

yep.

thanks,

David


>
> -- Sanjoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160229/981a6839/attachment.html>