[PATCH][RFC] HLE support proposal

[Nadav Rotem]

Hi Michael, 

Thanks for the quick reply. 

> Sorry, the attached patches is for demonstration purpose only not for
> the final review. As I stated in the original email, it's neither final
> nor complete so far. But, with reference code, the proposal may be
> understood better.

It's 76K of code.  I think that it will be much more effective for you to write the mailing list before you code. 

> 
> There are two considerations:
> 
> One is to provide GCC/ICC compatibility. GCC (gcc-4.8) provides HLE
> functionality through existing atomic builtins by ORing HLE hint bits
> into the memory order word. These builtins are implemented in LLVM/Clang
> through atomic instructions. It's a straight-forward approach by hinting
> atomic instructions.

It is not a straight forward approach because it requires a new pre-isel pass, attaching metadata to instructions, etc.  Also, this solution increases the compile time of all generated x86 code (including debug builds) because it requires another scan of the IR.

Other compilers have other considerations and I don't think that we need to compromise compile time or flexibility for this, especially if we have other alternatives. 

> 
> The other is to provide a portable way supporting HLE in LLVM IR. With
> target supporting HLE, extra HLE hints provide the performance benefit.
> At the same time, the same IR will work correctly on targets without
> HLE. Programmer doesn't need to ship two versions of IR if they want to
> target on both processors with or without HLE.
> 

This is exactly what I want to avoid. I don't want to change the LLVM-IR to add support for HLE.  LLVM supports many targets with many exotic features, and these features are exposed to developers using intrinsics.  The correct way to extend the LLVM IR is to use intrinsics.   

>> 
>> 
>> Target specific intrinsics will allow HLE-aware synchronization
>> library writers and researchers who implement alternative programming
>> models to use HLE.
> 
> Checking HLE hint could achieve the same purpose and, at same time, the
> existing atomic semantic could be reused without checking new
> intrinsics.


Thanks,
Nadav


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130416/b2a83b4a/attachment.html>