[llvm-dev] setjmp in llvm

[Tim Northover via llvm-dev]

Hi Wael,

On 2 June 2017 at 14:50, Wael Yehia via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Aren't we breaking the as-if rule because the semantics of the program imply
> that the value of s is unknown after the setjmp (because you can enter main
> from the location of setjmp in the program).

Congratulations! You've found one of 2.5 valid uses for "volatile". In
C11 (7.3.2.1p3):

> All accessible objects have values, and all other components of the abstract machine have state, as of the time the longjmp function was called, except that the values of objects of automatic storage duration that are local to the function containing the invocation of the corresponding setjmp macro that do not have volatile-qualified type and have been changed between the setjmp invocation and longjmp call are indeterminate.

So the value of "s" is indeterminate because it's not declared
volatile. C++ inherits these rules and adds a couple more restrictions
about destructors.

> I'm trying to prevent llvm instruction motion around an intrinsic function call.

This is pretty much impossible in LLVM if you mean instructions LLVM
considers side-effect free (e.g. a simple "add"). It's theoretically a
pain in the neck when dealing with cycle-counters for performance.
Though in practice it usually doesn't matter much: LLVM usually
doesn't do anything problematic, and if it does putting the region of
interest into a noinline function tends to be enough.

Cheers.

Tim.