This is similar to the work Kristof did for ARM here: https://reviews.llvm.org/D49072
For now, I have only implemented the version that lowers the intrinsic using an LFENCE. I'm workign on a version that can be lowered as an LFENCE or lowered using the control flow speculation available, so users have the option just as they do in the ARM patch.
This is intended to add to the discussion rather than be a definitive patch relating to the way we will handle spot mitigations as far as the final API/implementation in LLVM goes. Any comments about the API, the way implemented this, or anything else are welcome.
Note: This lowering to an lfence appears to be the same method that gcc currently uses in their implementation of the builtin.
- Below is copied from https://reviews.llvm.org/D49073 -----
This is part of implementing a technique to mitigate against Spectre v1,
similar in spirit to what has been proposed by Chandler for X86_64 at
http://lists.llvm.org/pipermail/llvm-dev/2018-March/122085.html.
This patch adds a new builtin function that provides a mechanism for
limiting the effects of miss-speculation by a CPU.
This patch provides the clang-side of the needed functionality; there is
also an llvm-side patch this patch is dependent on.
We've tried to design this in such a way that it can be used for any
target where this might be necessary. The patch provides a generic
implementation of the builtin, with most of the target-specific
support in the LLVM counter part to this clang patch.
The signature of the new, polymorphic, builtin is:
T __builtin_speculation_safe_value(T v)
T can be any integral type (signed or unsigned char, int, short, long,
etc) or any pointer type.
The builtin assures that value v will be made 0 on execution paths that
are being executed under control flow miss-speculation by the CPU, when
the miss-speculated path originated due to misprediction of a direct
conditional branch.
Whereas this still leaves open the possibility of execution on a
miss-speculated path starting at misprediction of other control flow
instructions, our believe is that the above guarantee is still useful in
mitigating vulnerability to Spectre v1-style attacks and implementable
for most, if not all, target instruction sets.
This also introduces the predefined pre-processor macro
__HAVE_SPECULATION_SAFE_VALUE, that allows users to check if their
version of the compiler supports this intrinsic.
This line doesn't seem to be needed?