[PATCH] D62413: [OpenCL][PR41727] Prevent ICE on global dtors

John McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Jun 10 15:44:05 PDT 2019


rjmccall added inline comments.


================
Comment at: lib/CodeGen/CGDeclCXX.cpp:132
+      Argument = CGM.getTargetCodeGenInfo().performAddrSpaceCast(
+          CGM, Addr.getPointer(), SrcAS, LangAS::opencl_global, DestTy);
 
----------------
Anastasia wrote:
> rjmccall wrote:
> > Should this code be conditional to OpenCL?  And why does `_cxa_atexit` take a `__global` pointer instead of, say, a `__generic` one?
> The only objects that are destructible globally in OpenCL are `__global` and `__constant`. However `__constant` isn't convertible to `__generic`. Therefore, I am adding `__global` directly to avoid extra conversion. I am not yet sure how to handle `__constant`though and how much destructing objects in read-only memory segments would make sense anyway. I think I will address this separately.
The pointer argument to `__cxa_atexit` is just an arbitrary bit of context and doesn't have to actually be the address of a global.  It's *convenient* to use the address of a global sometimes; e.g. you can use the global as the pointer and its destructor as the function, and then `__cxa_atexit` will just call the destructor for you without any additional code.  But as far as the runtime is concerned, the pointer could be `malloc`'ed or something; we've never had a need to do that in the ABI, but it's good future-proofing to allow it.

So there are three ways to get a global destructor to destroy a variable in `__constant`:
- You can pass the pointer bitcast'ed as long as `sizeof(__constant void*) <= sizeof(__cxa_atexit_context_pointer)`.
- You can ignore the argument and just materialize the address separately within the destructor function.
- You can allocate memory for a context and then store the pointer in that.

Obviously you should go with the one of the first two, but you should make sure your ABI doesn't preclude doing the latter in case it's useful for some future language feature.  In other words, it doesn't really matter whether this argument is notionally in `__global` as long as that's wide enough to pass a more-or-less arbitrary pointer through.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62413/new/

https://reviews.llvm.org/D62413





More information about the cfe-commits mailing list