AlexVlx added a comment. In D153092#4452070 <https://reviews.llvm.org/D153092#4452070>, @yaxunl wrote:
> This could be a good chance to switch VT to constant address space instead of > global address space. AFAIK if a target has global addr space they usually > also has constant addr space since they usually support OpenCL or CUDA/HIP. > Is there any reason we cannot introduce a CGM.ConstantGlobalsInt8PtrTy and > use it for VT instead? I did give this some thought and the benefits are somewhat unclear to the point of being ultimately counterproductive. Note that these are already marked `constant`, which IIRC is / was going to be enough to get most of the benefits, at least on our back-end. Furthermore, the semantics of the constant address space are a bit weird in something like OpenCL e.g. `A pointer that points to the constant address space cannot be cast or implicitly converted to the generic address space.`. This would lead to weirdness when composing with CUDA / HIP, where `constant` is treated as `device`, which is to say global. IIRC, you are also meant to use magical interfaces to write into `constant` from the host, which a loader wouldn't necessarily do. Overall, I think that the OCL formulation of `constant` is actually meant to allow for relatively strange things like loading things into ROM or having different pointer types (be it width or canonicity). TL;DR, I am concerned that a target could validly have the `constant` addr space be disjoint from generic/flat, with no viable way to even cast between the two. We could say “yes, but this is not that `constant`”, but then if OCL ever starts supporting dynamic polymorphism it would get confusing. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D153092/new/ https://reviews.llvm.org/D153092 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
