[PATCH][RFC] HLE support proposal

[Evan Cheng]

Hi Michael,

Every new feature adds some complexity to llvm. So ultimately it comes down to whether the added functionality is worth the trade off. One missing bit of data here is who / what are the clients of HLE support. Can you elaborate?

>From your comments in this thread, it seems the motivation is to gain feature parity with gcc. That by itself is not really a strong enough argument since the two projects have different design goals. LLVM really isn't about having every last feature that it's competitions have.

LLVM has many features and it is being used in many ways. It is now being used in dynamic environment such as WebKit. We are getting concerned about its increasing heft and are thinking hard about putting it on a diet. You can understand why we question the cost of esoteric features such as HLE. 

Evan

Sent from my iPad

On Apr 17, 2013, at 3:54 PM, Michael Liao <michael.liao at intel.com> wrote:

> 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
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits