[LLVMdev] Intended semantics for ``fence seq_cst``

[JF Bastien]

> 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
be OK.


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
first launch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/2590876a/attachment.html>