[cfe-dev] Does a inline assembly or a memory barrier disable optimizations in a function

[Richard Smith]

On Aug 2, 2015 9:43 AM, "Jeffrey Walton" <noloader at gmail.com> wrote:
>
> On Sun, Aug 2, 2015 at 11:49 AM, Reid Kleckner <rnk at google.com> wrote:
> > That construct is just a memory barrier that applies to escaped objects.
> > Dead stores to unescaped locals for example will be removed during SSA
> > conversion.
> >
> OK, thanks. That should probably be documented because its different
> behavior from GCC.

GCC's behavior is the same: https://goo.gl/R5AMDG

> Its important information for someone writing a zeroizer for
> compliance reasons, like FIPS 140. (it might even cause a security
> related defect).
>
> Jeff
>
> > On Aug 1, 2015 9:29 PM, "Jeffrey Walton" <noloader at gmail.com> wrote:
> >>
> >> GCC disables optimizations in a function if it encounters inline
> >> assembly. That means we can use a memory barrier to ensure dead stores
> >> are not optimized out:
> >>
> >>     delete m_ptr;
> >>     m_ptr = NULL:
> >>
> >>     __asm__ __volatile__ ("" ::: "memory");
> >>
> >> Clang defines __GNUC__, but its not clear to me if the same behavior
> >> is present. Looking at Language Compatibility at
> >> http://clang.llvm.org/compatibility.html, there is no discussion of
> >> the behavior.
> >>
> >> Does inline assembly or a memory barrier tame the optimizer in a
> >> function so that dead stores are not removed?
> >>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150802/623ff11e/attachment.html>