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

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 24 23:12:45 PST 2016


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. 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 ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160225/fa578b0d/attachment.html>


More information about the llvm-dev mailing list