[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: "Hal Finkel" <hfinkel at anl.gov>, "Sanjoy Das" <sanjoy at playingwithpointers.com>
> 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 1:12:45 AM
> Subject: Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
> 
> 
> 
> 
> On Wed, Feb 24, 2016 at 10:56 PM Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> ----- 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 12:25:54 AM
> > Subject: Re: [llvm-dev] Possible soundness issue with
> > available_externally (split from "RFC: Add guard intrinsics")
> > 
> > 
> > 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).
> 
> If the undef is folded to some concrete value (instead of just being
> propagated), then yes, I agree. We really should be propagating the
> undef, however, right?
> 
> 
> 
> But we're allowed to fold it.

Apparently not as allowed as we thought. ;)

> And we do fold it to a concrete
> identity value in an operand of some operation all the time. Or as a
> function call argument. Or ...

Define "all the time"? We get undefs from actual undefined behavior at the language level, from "don't cares" in shuffle masks, etc. and it seems easy to construct cases where a function's readonlyness depends on how you fold the undef, but it is not clear that, in itself, this is problematic.

 -Hal

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