llvm dev - Jun 2014 - [LLVMdev] RFC: add "cmpxchg weak" to LLVM IR

Hi Chandler,
> So, I see where you're going here, but I'm curious -- why not just
switch
> ATOMIC_CMP_SWAP to have a second i1 value, and still be strong? Is this
> *just* to support expanding? I wonder if that's really useful rather
than
> just lowering it directly on the various targets....
I tried that originally, but quickly got into murky waters with all
the targets I've got basically no clue about.

It still could have been the best option (I started poking at Mips),
but for one particularly nasty facet: you can select ATOMIC_CMP_SWAP
in TableGen, but not ATOMIC_CMP_SWAP_WITH_SUCCESS (multiple results
and all that).

That means even getting selection back to the status quo would have
been a lot of duplicated C++ code in multiple targets, all for what's
basically a dead-end in most cases. It's far easier to make use of the
i1 before the DAG level if possible.

Anyway, that was my reasoning. Possibly more pragmatism than principle.

Cheers.

Tim.

On Fri, Jun 13, 2014 at 11:00 AM, Tim Northover <t.p.northover at
gmail.com>
wrote:
> Hi Chandler,
>
> > So, I see where you're going here, but I'm curious -- why not
just switch
> > ATOMIC_CMP_SWAP to have a second i1 value, and still be strong? Is
this
> > *just* to support expanding? I wonder if that's really useful
rather than
> > just lowering it directly on the various targets....
>
> I tried that originally, but quickly got into murky waters with all
> the targets I've got basically no clue about.
>
> It still could have been the best option (I started poking at Mips),
> but for one particularly nasty facet: you can select ATOMIC_CMP_SWAP
> in TableGen, but not ATOMIC_CMP_SWAP_WITH_SUCCESS (multiple results
> and all that).
>
> That means even getting selection back to the status quo would have
> been a lot of duplicated C++ code in multiple targets, all for what's
> basically a dead-end in most cases. It's far easier to make use of the
> i1 before the DAG level if possible.
>
> Anyway, that was my reasoning. Possibly more pragmatism than principle.
>
No, it makes a certain amount of sense.

I'd personally much rather we had *just* the multiple result variant in the
DAG, but I can see it being really annoying to get there directly. Perhaps
eventually targets will have adapted far enough that we can kill off the
expanded form, or invert them.

Certainly, I agree with only exposing the strong variant once you hit the
DAG.

So, I say carry on unless others on the list see serious problems here.
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140613/9264e5d8/attachment.html>

> So, I say carry on unless others on the list see serious problems here.
Will do; thanks very much for giving this some thought.

Tim.