[PATCH] D104151: [docs][OpaquePtr] Shuffle around the transition plan section

[Arthur Eubanks via Phabricator via llvm-commits]

aeubanks added inline comments.


================
Comment at: llvm/docs/OpaquePointers.rst:140-143
+* Figure out how to name overloaded intrinsics with pointer parameters
+
+  * See ``getMangledTypeStr()``
+
----------------
dblaikie wrote:
> aeubanks wrote:
> > dblaikie wrote:
> > > Oh, yeah. I remember that one.
> > > 
> > > Are there cases you know of where we will need overloading based on pointee type? Or might it be a case of mangling opaque pointer types as opaque being sufficient?
> > So far I've found D61524 that needs to be done.
> > But I'm confused about your question. We won't have pointee types, so we won't be able to mangle based on pointee type, we can only mangle opaque pointers as opaque pointers (with their address space).
> What I mean is are there intrinsics that have different behavior based on the pointee type (ie: a function that takes only a pointer parameter, but actually has different behavior (I could imagine something like a typed memcpy where the type information (size of elements to copy) is communicated through the pointee type)) - or, to the best of our current knowledge, the intrinsic overloading for pointee types is only because it's necessary for those functions to have different names to account for the different parameters (and not require bitcasts for every parameter) but have the same implementation.
Ah I haven't looked through all of the intrinsics, I've only stumbled upon D61524 so far, which isn't exactly specializing implementations per pointee type, rather just looking at the pointee type.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104151