The issue was originally found in a larger benchmark, but can be also shown with targeted tests.

In short, on x86, we emit "lock addl %(esp+0), 0" as the substitute for StoreLoad barrier, and while this thing seems faster than "mfence", we interfere with things residing on the top of the stack: call arguments, for one example. The interaction appears to be either the true data dependency via %(esp+0), or the implicit dependency via the cache line containing %(esp+0) locked with lock-prefixed instruction.

This bug suggests to reconsider the instruction sequence emitted for the StoreLoad barrier, see comments.