[PATCH] D95142: [SLC] Simplify strcpy and friends with non-zero address spaces

Alexander Richardson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 21 08:41:12 PST 2021


arichardson added inline comments.


================
Comment at: llvm/lib/Analysis/TargetLibraryInfo.cpp:647-649
+      if (DL &&
+          PTy->getPointerAddressSpace() != DL->getDefaultGlobalsAddressSpace())
+        return false;
----------------
arsenm wrote:
> jrtc27 wrote:
> > arichardson wrote:
> > > arsenm wrote:
> > > > This wouldn't really be right for AMDGPU, but we have no library calls anyway. I also think it's not right to use GlobalsAddressSpace for this purpose. This has nothing to do with globals or creating new values
> > > More than happy to drop this restriction and just accept any i8*.
> > > 
> > > I guess something like a "malloc/heap" address space would be more accurate since it's used when checking the `realloc` return value. It doesn't really matter too much for CHERI since we use 200 for program+alloca+globals.
> > The issue is there's no notion of "the address space that libfuncs use". The additional granularity for globals vs stack (vs others too maybe?) is unhelpful here; for us they'll all be the same (AS 200), but there is no sensible mapping from C language `void *` (or, in this case, `char *`) to the AS in use.
> I believe the current precedent assumes libcalls must use address space 0
Unfortunately we can't use AS0 for CHERI due to compatibility with with MIPS/RISC-V/AArch64.

Would you be okay with me replacing the `== PCharTy` with `->isPointerType()`? That would allow us to simplify these libcalls and also doesn't depend on the pointee type any more.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95142



More information about the llvm-commits mailing list