On 3 Mar 2013, at 19:19, Jeffrey Yasskin <[email protected]> wrote:
> It would be nice if the LLVM optimizers could get this instead of > needing the frontend to do it. 'course, compile time might argue for > having the frontend do it _also_. It might be, but it's also quite difficult, because the compare-exchange loops might be relatively complex. It might be more interesting to be able to model load-link and stored-conditional in the IR. This abstraction exists across a lot of back ends and I think there are still quite a lot of cases where we're emitting some duplicate loads. There are several cases where we could do some better optimisation, and it might be better to do this in the IR, having a pass that turned cmpxchg loops into ll / sc. I also think that we're going to be missing some weak-cmpxchg-related optimisations with the current model. The cmpxchg code path here does the same thing as the non-atomic version, so it should be right, just not necessarily the most efficient. I've tried to ensure that we generate good code where I'm sure of the semantics. David _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
