[PATCH][RFC] HLE support proposal

[Nadav Rotem]

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. 

> 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

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