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

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 11 15:24:37 PDT 2021


dblaikie added inline comments.


================
Comment at: llvm/docs/OpaquePointers.rst:140-143
+* Figure out how to name overloaded intrinsics with pointer parameters
+
+  * See ``getMangledTypeStr()``
+
----------------
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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104151



More information about the llvm-commits mailing list