> You will need to do this in the frontend. The target independentoptimizers are allowed to use the memory model. We discussed doing this, and concluded that doing it pre-opt was overly restrictive on correct code. Doing it post-opt bakes the behavior into the portable code, so in a way it'll be reliably broken but won't penalize good code. FWIW it's easy to change from one to the other: move one line of code. I hope my explanation makes sense, and it doesn't look like I'm dismissing your comment on implementation issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/fdd46a7c/attachment.html>
On Wed, Jul 31, 2013 at 6:39 PM, JF Bastien <jfb at google.com> wrote:> > You will need to do this in the frontend. The target independent > optimizers are allowed to use the memory model. > > We discussed doing this, and concluded that doing it pre-opt was overly > restrictive on correct code. Doing it post-opt bakes the behavior into the > portable code, so in a way it'll be reliably broken but won't penalize good > code. > > FWIW it's easy to change from one to the other: move one line of code. I > hope my explanation makes sense, and it doesn't look like I'm dismissing > your comment on implementation issues. >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... As Jeffrey pointed out, the penalty is relatively low on x86. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/0b168e1e/attachment.html>
> 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>