[llvm-dev] _mm_lfence in both pathes of an if/else are hoisted by SimplfyCFG potentially breaking use as a speculation barrier

[Craig Topper via llvm-dev]

_mm_lfence was originally documented as a load fence. But in light of
speculative execution vulnerabilities it has started being advertised as a
way to prevent speculative execution. Current Intel Software Development
Manual documents it as "Specifically, LFENCE does not execute until all
prior instructions have completed locally, and no later instruction begins
execution until LFENCE completes".

For the following test, my intention was to ensure that the body of either
the if or the else would not proceed until any speculation of the branch
had resolved. But SimplifyCFG saw that both control paths started with an
lfence so hoisted it into a single lfence intrinsic before the branch.
https://godbolt.org/z/qMc446    The intrinsic in IR has no properties so it
should be assumed to read/write any memory. But that's not enough to
specify this control flow dependency. gcc also exhibits a similar behavior.

#include <x86intrin.h>

void bar();
void baz();

void foo(int c) {
  if (c) {
      _mm_lfence();
      bar();
  } else {
      _mm_lfence();
      baz();
  }
}


Alternatively, I also tried replacing the intrinsics with inline assembly.
SimplifyCFG still merged those. But gcc did not.
https://godbolt.org/z/acnPxY

void bar();
void baz();

void foo(int c) {
  if (c) {
      __asm__ __volatile ("lfence");
      bar();
  } else {
      __asm__ __volatile ("lfence");
      baz();
  }
}

I believe the [[clang::nomerge]] attribute was recently extended to inline
assembly which can be used to prevent the inline assembly from being
hoisted by SimplifyCFG https://reviews.llvm.org/D84225    It also appears
to work for intrinsic version, but I think its limited to C++ only.

Is there some existing property we can put on the intrinsic to prevent
SimplifyCFG from hoisting like this? Are we more aggressive than we should
be about hoisting inline assembly?

Thanks,
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200728/5224ee14/attachment.html>