[PATCH] D20555: [MemCpyOpt] Be conservative in the face of returns_twice calls

David Majnemer via llvm-commits llvm-commits at lists.llvm.org
Thu May 26 00:50:32 PDT 2016

majnemer added a comment.

In http://reviews.llvm.org/D20555#440527, @sanjoy wrote:

> I'm fine being bugged, but I think this review is missing some context -- how is "volatile stores escape the location being stored to" related to how we handle `setjmp` / `longjmp`?

We substituted the underlying storage for a pointer when calling some function, that function would later perform a volatile store to that pointer.  This is important because `setjmp` and `longjmp` require any modifications to objects which are loaded after the `longjmp` to be performed with `volatile` accesses.  This all falls apart if the wrong underlying object is stored to.

> A explicit test case on why we need this new rule will also be helpful (if not as a test case, then an example in the commit message), since `@test_volatile` only checks that we implement the rule correctly, but does not explain what the motivation is.


More information about the llvm-commits mailing list