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

[Chandler Carruth via llvm-dev]

On Wed, Feb 24, 2016 at 10:25 PM Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

>
> Hal Finkel wrote:
>
>  > But it is not all optimizations that are the problem. Rather, it
>  > seems like a select few (e.g. things involving collapsing allowed
>  > non-determinism in atomics), and losing those optimizations seems
>  > better than generally losing function-attribute deduction.
>
> If we go by the langref, then optimizations that fold undef are also
> problematic (though most C/C++ programs resulting in such IR would
> have UB in practice).
>

I'm also concerned about undef. It isn't clear that we can reasonably
ensure that all things involving undef suitably stem from UB in the face of
speculation to preclude all "impossible" results coming from interposition.

I think trying to enumerate the function-local optimizations which are
unsafe is *much* more challenging than identifying the interprocedural
optimizations which are unsafe, which is essentially what disabling
function attribute deduction is doing.


>
> I think there are non-(non-deterministic) problematic cases too.  The
> following won't happen today since `readnone` does not imply
> `safe_to_speculate`, but if we add a `safe_to_speculate` property some
> day:
>
>    int foo(bool C) available_externally {
>      if (C)
>        ((int *) null)++; // UB
>      ret 42;
>    }
>
>    void bar() {
>      if (<some cond>)
>       foo(true);
>    }
>
> Now, normally you can just delete the `if (C)` branch in foo, and it
> would become just a `ret 42`, and would look like it is speculatable
> above the `<some cond>` check.  But if you then link with an -O0
> version, you'll have introduced UB if `<some cond>` is always false at
> runtime.
>
> Today this won't happen since we don't speculate `readnone nounwind`
> functions, but could become a problem in the future.
>

All of this makes me think we're just seeing the tip of the iceberg of ways
in which local optimizations can combine with attributes to break this. =/
I really think the problem is as Richard describes the interprocedural
movement of information across a comdat-like boundary where replacements
may occur with differently transformed code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160225/c2f8883d/attachment.html>