Today, we do not allow cmpxchg operations with pointer arguments. We require the frontend to insert ptrtoint casts and do the cmpxchg in integers. While correct, this is problematic from a couple of perspectives:
- It makes the IR harder to analyse (for instance, it make capture tracking overly conservative)
- It pushes work onto the frontend authors for no real gain
This patch implements the simplest form of IR support. As we did with floating point loads and stores, we teach AtomicExpand to convert back to the old representation. This prevents us needing to change all backends in a single lock step change. Over time, we can migrate each backend to natively selecting the pointer type. In the meantime, we get the advantages of a cleaner IR representation without waiting for the backend changes.
Is there a reason to disallow floating point types? C11 expects compare and exchange to work on floating point types, and requiring casts to integer types doesn't play particularly nicely with TBAA.
Given the recent mailing list discussion, is this part of the work to allow the front end to provide any type here and lower to a library call closer to the back end?