[PATCH][RFC] HLE support proposal

[Chris Lattner]

Michael,

On Apr 18, 2013, at 1:49 PM, "Liao, Michael" <michael.liao at intel.com> wrote:
> As locks are widely used in all kinds of applications, hardware lock elision is an attractive technology to improve locking with minimal or evolutionary changes. Because it's not introducing a brand new, full transactional memory programming model, it's more acceptable technique for a better locking. From what I learned, many system components are get hardware lock elision supported, such as libstdc++, glibc, pthread, Linux kernel, and etc. The number of application using it or experimenting with it is constantly growing, especially considering the new hardware is available soon. 

I don't think that anyone here is objecting to LLVM supporting HLE as a feature, they are just discussing the best way to implement the feature.  I think that many people would love to get proper HLE support, but we need to implement it in the right way.

> Compatibility to GCC

Source level compatibility with GCC and ICC are definitely interesting (and important), but I don't see why that would imply a specific implementation approach.  For example, clang supports xmmintrin.h (and friends) for compatibility with ICC and GCC, but *implements* them in completely different ways.

> is just one of the considerations and the major design consideration is that an HLE hinted atomic instruction (LLVM IR) is still an atomic instruction. It won't break the existing optimizations but leverage the existing optimizations aware of atomic instruction, e.g. reducing memory barriers as much as possible. Otherwise, we have to introduce target specific optimizations duplicating these optimizations.

I don't understand the motivation here - what optimizations are you anticipating?  Most existing LLVM operations detect atomics and back off very quickly, so you're not getting any specific optimizations in practice.

I share the general concern that you are adding substantial complexity for a single (admittedly important!) target, and gaining very little win for the additional complexity.

-Chris