[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...
More information about the llvm-dev