<div class="gmail_quote">On Mon, Apr 26, 2010 at 11:46 AM, David Greene <span dir="ltr"><<a href="mailto:dag@cray.com">dag@cray.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Monday 26 April 2010 10:19:06 Renato Golin wrote:<br>
> On 26 April 2010 15:59, Jeffrey Yasskin <<a href="mailto:jyasskin@google.com">jyasskin@google.com</a>> wrote:<br>
> > To be clear, Chandler wasn't suggesting any change to the existing<br>
> > load and store instructions. Instead, we were wondering if people like<br>
> > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe<br>
> > atomic_exchange and atomic_add instructions.<br>
><br>
> I see, in that case, I don't have any strong opinion. Maybe new<br>
> instructions would be simpler and cleaner...<br>
><br>
> I quite like the idea of having more expressive atomic operators, as<br>
> it'll be easier to map high-level synchronization concepts to IR.<br>
<br>
</div>I don't have a strong preference, but I am curious why all the atomics<br>
are integer-only.  I would like to see 32- and 64-bit float supported as<br>
well, at minimum.<br></blockquote><div><br></div><div>I have no real problem with making the types of all of these analogous to the types supported by icmp, and providing floating point atomics as well. A couple of observations:</div>
<div><br></div><div>Allowing direct use of pointers would be convenient I suspect -- pointers are very common operands to atomic operations, and it seems annoying to have to convert them to ints.</div><div><br></div><div>
We can allow the IR to represent vectors, but unless hardware supports it, I think lowering these by decomposing them is more than LLVM should try to do. Because of that, I'm not sure we should support vectors as elsewhere they degrade gracefully.</div>
</div>