[PATCH][RFC] HLE support proposal

[Michael Liao]

Hi Nadav

On Wed, 2013-04-17 at 15:43 -0700, Nadav Rotem wrote:
> 
> On Apr 17, 2013, at 1:36 PM, Michael Liao <michael.liao at intel.com>
> wrote:
> 
> > Hi Nadav
> > 
> > I cannot follow your statement on complexity and complexity. Could
> > you
> > give me more concrete reasons? Broadly speaking of that definitely
> > won't
> > help us to revise the proposal.
> > 
> 
> 
> You are increasing the compile time by adding a new pass that needs to
> run over all of the code that the X86 backend needs to run.  You are
> adding unnecessary complexity by adding target specific semantics
> LLVM's IR and by adding a new pass. Your proposal is completely
> unscalable. We can't add new passes and new metadata to support every
> little feature. If we go down this road we'll have dozens of target
> specific passes, tricks and hooks all over the compiler. The
> maintainability of the compiler, as well as the compile time for
> people who don't care about feature is more important. And what is the
> gain of all this ? Just the ability to run LLVM's optimizations for
> atomic instruction ? Do you really have workloads that benefit from
> these optimizations ? At the end of the day there is a tradeoff
> between atomic optimizations for HLE atomic operations (which you even
> failed to mention what they are) and the added complexity to the
> compiler. 

This new is introduced as a way to move away from SelectionDAG compared
to previous proposal. This new pass could be revised to be applied to
targets supporting HLE and this new pass could be skipped totally by
keeping tracking whether a function has atomic instructions used.

BTW, the pass itself, even it's written in x86', is intended to a
general pass. This pass itself is targeted to simplify backend support
of atomic instructions by reusing CAS/LLSC loop as much as possible.
That's why LLSC is added (LLSC is supported on almost all RISC
processors but not on x86.)

For LLVM IR hinting only, putting this pass aside (since it's targeted
to DAG issue in last proposal.), could you elaborate details on why it
adds complexity in compiler.

- Michael


> 
> > I don't why you insists on implementing HLE as separate intrinsics
> > without considering all the comments previously we raised. HLE needs
> > to
> > leverage the existing optimization on atomic instructions. Adding
> > them
> > as separate intrinsics will add significant overhead on duplicating
> > these optimizations and breaking layered design, not less to say how
> > many intrinsics we needed.
> > 
> > Yours
> > - Michael
> > 
>