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

On Wed, Feb 24, 2016 at 11:18 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 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.
The only optimizations I can think of that are okay are algebraic
simplifications that don't exploit no-overflow, inbounds or exact
flags and CFG simplifications like loop unswitch and loop unroll (that
don't actually change the trace that we'll see at runtime).

-- Sanjoy

----- Original Message -----
> From: "Sanjoy Das" <sanjoy at playingwithpointers.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Chandler Carruth" <chandlerc at google.com>,
"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 1:38:48 AM
> Subject: Re: [llvm-dev] Possible soundness issue with available_externally
(split from "RFC: Add guard intrinsics")
> 
> On Wed, Feb 24, 2016 at 11:18 PM, Hal Finkel <hfinkel at anl.gov>
wrote:
> 
> > 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.
> 
> The only optimizations I can think of that are okay are algebraic
> simplifications that don't exploit no-overflow, inbounds or exact
Why? Can you provide an example using nsw, inbounds, etc.?

 -Hal
> flags and CFG simplifications like loop unswitch and loop unroll
> (that
> don't actually change the trace that we'll see at runtime).
> 
> -- Sanjoy
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On Wed, Feb 24, 2016 at 11:44 PM, Hal Finkel <hfinkel at anl.gov>
wrote:
>> The only optimizations I can think of that are okay are algebraic
>> simplifications that don't exploit no-overflow, inbounds or exact
>
> Why? Can you provide an example using nsw, inbounds, etc.?
I think the same case as the general UB applies:

void foo(int n) available_externally {
  if (n s< (n +nsw 1)) abort();
}

void bar() {
  if (< runtine cond always false>)
    foo(INT_SMAX);
}

Now foo() can be simplified to "ret void" using the nsw, and the call
to foo(INT_SMAX) can be hoisted.  This is a problem if we link to an
unrefined @foo.

-- Sanjoy