[PATCH][RFC] HLE support proposal

[Nadav Rotem]

> Here, I am only talking hinting atomic instruction IR with HLE. Hinting
> existing atomic instruction is straight-forward as it captures the goal
> maintaining a portable IR between target with HLE and the one without
> HLE. In addition, all atomic-aware optimizations will work the same.

You are still proposing to change the IR by adding new metadata.

> For this proposal, adding a lower pass isn't straightforward compared to
> add trivial feature in SelectionDAG directly but it still obvious enough
> to understand.

Neither one of these changes is trivial. Both are very intrusive. People who don't care about HLE can't opt-out and have to pay the cost of the added complexity and compile time (see below). 

> The major benefit after adding a lowering pass
> translating atomic instruction into target native atomic intrinsic is:
> it will reduce burden of implementing all atomic instructions on the
> backend side. Most target hardwares only provide the minimal atomic
> support instructions (i.e. LL/SC in all RISC targets), with this pass,
> those targets only need to care the codegen of LL/SC.

Why is it the job of the compiler to implement HLE-intrinsics on non-HLE targets ? It needs to be in a library. 

>> 
>> 
>> 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. 
> 
> Could you elaborate the compile time overhead? From my measure, this
> pass is fast as this pass has O(N) complexity and only processes atomic
> instructions. If we could keep tracking whether a function has atomic
> instruction or not, we could be even faster by skipping them totally.
> 

Yes, its an O(N) pass that scans all of the instructions and does something with some of the instructions. The problem is that most people who don't care about will still have to pay the cost of the HLE implementation. 

> I agree with you on one hardware features like CRC, encryption, but not
> HLE feature, which is a common feature for hardware with TM support.

I don't think that HLE is very common. 

> I
> don't think GCC community doesn't consider the approach you mentioned.
> In fact, if you look into GCC mailing list, people rejected that
> proposal originally and preferred the approach hinting atomic builtins.

I would like to see the HLE features implemented as intrinsics from start to finish without adding any burden on the rest of the compiler.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130417/fb067db4/attachment.html>