[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