[PATCH][RFC] HLE support proposal

[Eric Christopher]

Hi Nadav,

On Tue, Apr 16, 2013 at 10:16 PM, Nadav Rotem <nrotem at apple.com> wrote:
>
> On Apr 16, 2013, at 6:34 PM, Michael Liao <michael.liao at intel.com> wrote:
>
> an alternative approach is proposed to refactor atomic
> instruction code generation, enable HLE hint to be passed into backend
> and hence enable HLE code generation.
>
>
> Hi Michael,
>
> Thanks for working on this, but I really prefer that you discuss your
> proposal with the mailing list before you send patches. You are putting the
> reviewers in a position where its difficult to make suggestions or propose
> alternatives. This is especially important for such intrusive patches.
>

I don't think this is a fair or even worthwhile statement to make for
the project. He's proposed an idea and given some patches illustrating
his idea. i.e. he just gave you a proposal and some code to show that
it's possible to implement as he describes. This shows both
forethought and a willingness to try out an idea instead of just
proposing an empty spec.

> Last time you sent the HLE patches I suggested that you implement HLE as
> intrinsics. I don't understand why HLE needs to be more than a group of
> intrinsics, from start-to-finish. Why do you need code other than intrinsics
> ?
>
> Target specific intrinsics will allow HLE-aware synchronization library
> writers and researchers who implement alternative programming models to use
> HLE.
>

He responded in the original (now 45 message) thread about this and
you never replied:

"The reason why X86-specific intrinsic is not used for X86 HLE support is
that it will introduce significant interface change due to the number of
atomic instructions. Developer will make non-small modification to
change from previous atomic builtins provided by clang/llvm to X86
intrinsic-based HLE interface. That's why GCC community propose to add a
target hint for all atomic builtins. In addition, LLVM treat intrinsics
differenet from atomic insns, we will lose chances of optimizations.

In the other side, HLE support doesn't rely on TM support directly. Even
though I put example showing HLE could be implemented upon TM-only.
That's should be a future work once TM is within LLVM roadmap. Before
that, if a target needs provide HLE interface, it could provides them
through their native code generation."

I've not personally looked into the technical aspects of the proposal,
but he has replied to your concerns and I felt that your earlier
statement needed to be replied to.

-eric