cmpxchg only support exchange on int operands, but pointer values can be very useful here, e.g. stack in a linked-list, the top can be atomic<Node>.
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?
You can bitcast to pointer-sized int!
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.
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.
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.
Again, agreed. Though, frankly, this is much less important to me.
One subset of David's proposal that would be very useful is to allow cmpxchg of arbitrary types whose size is less-than-equal the largest the target supports. In practice, this is what the frontend does anyways (with the additions of casts). It exposes some target specific details in the IR, but no more than is already exposed.
Worth noting is that all of the points we've made here w.r.t. cmpxchg also apply to ordered ("atomic") loads and stores.