cmpxchg only support exchange on int operands, but pointer values can be very useful here, e.g. stack<T> in a linked-list, the top can be atomic<Node<T>*>. in clang++, cmpxchg operations on atomic<T*> are bitcasted i64 and do the operation, which is ugly. Any reason or concern why cmpxchg doesn't support pointer operands? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140906/a816925b/attachment.html>
You can bitcast to pointer-sized int! -Filip> On Sep 6, 2014, at 2:31 PM, Chuan Qiu <qiuc12 at gmail.com> wrote: > > cmpxchg only support exchange on int operands, but pointer values can be very useful here, e.g. stack<T> in a linked-list, the top can be atomic<Node<T>*>. > in clang++, cmpxchg operations on atomic<T*> are bitcasted i64 and do the operation, which is ugly. > > Any reason or concern why cmpxchg doesn't support pointer operands? > > Thanks > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140906/5025e5e2/attachment.html>
I didn't say I can't do it, but feel it's somewhat hacking: need align of 64 bit for pointer types, and need unnecessary casting. On Sat, Sep 6, 2014 at 3:57 PM, Filip Pizlo <fpizlo at apple.com> wrote:> You can bitcast to pointer-sized int! > > -Filip > > On Sep 6, 2014, at 2:31 PM, Chuan Qiu <qiuc12 at gmail.com> wrote: > > cmpxchg only support exchange on int operands, but pointer values can be > very useful here, e.g. stack<T> in a linked-list, the top can be > atomic<Node<T>*>. > in clang++, cmpxchg operations on atomic<T*> are bitcasted i64 and do the > operation, which is ugly. > > Any reason or concern why cmpxchg doesn't support pointer operands? > > Thanks > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140906/44a93e74/attachment.html>
On 6 Sep 2014, at 23:57, Filip Pizlo <fpizlo at apple.com> wrote:> You can bitcast to pointer-sized int!As I've mentioned before when this is brought up - not always. On the architecture I'm working on, for example, fat pointers are bigger than the largest integer register and can not be treated as integers. The same is true for some microcontrollers, where integer and address registers are different sizes. David
This has been brought up a couple times now. I don't believe anyone has voiced strong objection to having a variant which directly takes pointers, but no one has proposed a patch either. p.s. I'm solidly in the "it would be nice to see" camp. For much the same reasons as David. Philip On 09/06/2014 02:31 PM, Chuan Qiu wrote:> cmpxchg only support exchange on int operands, but pointer values can > be very useful here, e.g. stack<T> in a linked-list, the top can be > atomic<Node<T>*>. > in clang++, cmpxchg operations on atomic<T*> are bitcasted i64 and do > the operation, which is ugly. > > Any reason or concern why cmpxchg doesn't support pointer operands? > > Thanks > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140908/c7000510/attachment.html>
On 8 Sep 2014, at 21:09, Philip Reames <listmail at philipreames.com> wrote:> This has been brought up a couple times now. I don't believe anyone has voiced strong objection to having a variant which directly takes pointers, but no one has proposed a patch either. > > p.s. I'm solidly in the "it would be nice to see" camp. For much the same reasons as David.I'm also in two minds about whether it would be a good idea to allow the atomic cmpxchg to support arbitrary types. With RTM, for example, you might want to lower an atomic exchange of a structure to a begin-transaction, memcmp, memcpy, end-transaction block. Elsewhere, you lower it to a call to a helper function that does the right thing. Currently, this decision is made in the front end, but that removes some potential optimisation opportunities. David