[PATCH] Add HLE target feature

[Chandler Carruth]

On Wed, Feb 27, 2013 at 6:08 PM, Nadav Rotem <nrotem at apple.com> wrote:

> Hi Jeffrey,
>
> it's an extra argument passed through some layers and an extra level of
> arrays in
> some other layers.
>
>
> This patch adds complexity to multiple layers of the compiler, and I would
> like to understand the motivation before we add this complexity (and
> compile time).
>

Nadav, both Jeffrey and I have written several emails explaining why we
think that there are some good motivations.

Your only objections to what we've said apply equally well to atomic
operations. Jeffrey, Owen, and I helped build the motivation document and
spec for putting atomics support into the IR. Are you questioning the
utility of having atomics modeled in LLVM? Or is there something specific
to HLE that you think is questionable?

You stated that we give up and don't try to optimize atomic loads and
stores, but that isn't true. We have a spec for them, and can reason
precisely about their behavior as a result. I know for a fact that SROA
will remove atomic loads and stores, and there are other cases as well.
None of this can be true if the synchronization is implemented in inline
asm as you suggest.

If you have a specific concern with HLE, please express it. Continually
asserting that "this clearly belongs in a library" or other sweeping
assertions isn't helping here, as the people who are responsible for
building the IR's memory model and atomic model have disagreed. You're
going to need to explain your reasoning here so that we can actually
discuss any issue.

If you have a generic concern with being able to express the primitive
operations that make up synchronization constructs in the LLVM IR, you're
asking for a radical shift in direction of the project, and one which I
strongly oppose. It should also be a completely separate discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130227/a345c192/attachment.html>