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

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Chandler Carruth" <chandlerc at google.com>
> To: "Sanjoy Das" <sanjoy at playingwithpointers.com>, "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" <listmail at philipreames.com>, "Duncan P. N. Exon Smith"
> <dexonsmith at apple.com>
> Sent: Thursday, February 25, 2016 12:40:53 AM
> Subject: Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
> 
> 
> 
> 
> 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.
> 

It might be much more challenging, but let's try. This is not an issue we need to fix by the end of the month, and the potential optimization regressions are significant. Our deductions of readonly/readnone/nocapture/etc. are really important for enabling other optimizations. Given that all of our C++ constructors, inline functions, etc. end up in comdat sections, this is really important.

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

Yes, but it is not *all* information that is relevant here.

 -Hal

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory