Add support for _InterlockedCompareExchangePointer, _InterlockExchangePointer,
_InterlockExchange. These are available as a compiler intrinsic on ARM and x86.
These are used directly by the Windows SDK headers without use of the intrin
|139 ↗||(On Diff #10512)|
I don't think these intrinsics need the special overload handling that the __sync intrinsics require. They should just need type checking that's already described by Builtins.def.
|145–147 ↗||(On Diff #10512)|
The AST should reflect the code the user wrote, and we shouldn't be doing this kind of rewrite. The overload resolution in the existing checking code is different, it's taking something that the user wrote and annotating it with all the implicit conversions that should occur.
This should have it's own lowering in CGBuiltin.cpp.
Getting rid of __cdecl is actually quite important since this header is not x86 specific. ARM does not honour __cdecl, and thus generates a warning.
Good catch about the static __inline__. I've become too accustomed to the LLVM style and didnt notice that.
lgtm with some nits
MSVC doesn't provide this in 32-bit mode, but I think we can go ahead and do that anyway.
I'd like this to be factored better, but I can live with it as is.
CGM.Int32Ty doesn't seem correct for x64, it should be IntType.
MSDN says "Comparand" with an 'a'.
MSDN says the 'Dest' is volatile, so I'd call Result->setVolatile(true) here.
Id be willing to do a follow up change to disable this at the sema level in 32-bit x86 only if you like. This is available in 32-bit ARM.
Dest itself is volatile, the returned value is not. We dont strip volatility off of Destination. Oh, and I dont see a llvm::Value::setVolatile either.
No need. I always thought it was silly that they didn't go back and add this intrinsic for x86.
CreateAtomicCmpXchg should return an AtomicRMWInst* which can be made volatile. It's not the result that's volatile, it's the memory update.