[LLVMdev] Intended semantics for ``fence seq_cst``
jfb at google.com
Wed Jul 31 23:31:00 PDT 2013
> It doesn't really make sense to me. The most likely way for the optimizer
> to break any of this is in the middle end. By only fixing it afterward, I
> don't see what the advantage of fixing it at all is...
Actually I think you're right: we also transform atomics to stable
intrinsics, which we then transform back to LLVM IR on the user-side. Using
these intrinsics pre-opt would be detrimental to overall performance, but
doing volatile->atomic pre-opt and doing atomic->intrinsic post-opt should
As Jeffrey pointed out, the penalty is relatively low on x86.
Yes, we discussed performance of our approach extensively for x86-32,
x86-64, ARM, MIPS and other potential targets. Our current approach isn't
the best one for performance but it's definitely conservative, potentially
more portable in the face of bugs, while still being fast-ish and allowing
us to loosen up in future releases. It seems like a nice tradeoff for a
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev