[clang] [Cuda] Handle -fcuda-short-ptr even with -nocudalib (PR #111682)

Artem-B wrote: > I'm not sure why the option isn't enabled by default, personally While it does indeed help with generating better code, using this option while compiling CUDA code may be problematic. Front-end is not aware of address spaces and all pointers are generic, so `sizeof(any pointer

[clang] [Cuda] Handle -fcuda-short-ptr even with -nocudalib (PR #111682)

jhuber6 wrote: We don't need marshalling because this isn't a cc1 option. This is just handled by the driver which forwards it as `-mllvm` to the backend. You'd need to update the LLVM option to take multiple options and then make the clang driver option pick between them. https://github.com/

[clang] [Cuda] Handle -fcuda-short-ptr even with -nocudalib (PR #111682)

frasercrmck wrote: > > > I'm not sure why we would ever want the current default if this is an > > > option. I'm trying to see it, but I can't work out a case where a 64bit > > > pointer would make sense, since the even tens-of-thousands of money > > > supercomputer cards have less than 256KiB

[clang] [Cuda] Handle -fcuda-short-ptr even with -nocudalib (PR #111682)

https://github.com/frasercrmck edited https://github.com/llvm/llvm-project/pull/111682 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Cuda] Handle -fcuda-short-ptr even with -nocudalib (PR #111682)

https://github.com/frasercrmck closed https://github.com/llvm/llvm-project/pull/111682 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Cuda] Handle -fcuda-short-ptr even with -nocudalib (PR #111682)

frasercrmck wrote: > > I'm not sure why we would ever want the current default if this is an > > option. I'm trying to see it, but I can't work out a case where a 64bit > > pointer would make sense, since the even tens-of-thousands of money > > supercomputer cards have less than 256KiB of addr

[clang] [Cuda] Handle -fcuda-short-ptr even with -nocudalib (PR #111682)

jhuber6 wrote: > I'm not sure why we would ever want the current default if this is an option. > I'm trying to see it, but I can't work out a case where a 64bit pointer would > make sense, since the even tens-of-thousands of money supercomputer cards > have less than 256KiB of addressable shar

[clang] [Cuda] Handle -fcuda-short-ptr even with -nocudalib (PR #111682)

ldrumm wrote: I'm not sure why we would ever want the current default if this is an option. I'm trying to see it, but I can't work out a case where a 64bit pointer would make sense, since the even tens-of-thousands of money supercomputer cards have less than 256KiB of addressable shared memory.

[clang] [Cuda] Handle -fcuda-short-ptr even with -nocudalib (PR #111682)

frasercrmck wrote: > > > Seems reasonable, which architectures require this? I know that NVIDIA > > > deprecated the 32-bit `nvptx` target in CUDA 12 or something. > > > > > > I'm not an expert on CUDA but, AFAICT, even in 64-bit CUDA, certain > > pointers such as those pointing to shared mem

[clang] [Cuda] Handle -fcuda-short-ptr even with -nocudalib (PR #111682)

jhuber6 wrote: > > Seems reasonable, which architectures require this? I know that NVIDIA > > deprecated the 32-bit `nvptx` target in CUDA 12 or something. > > I'm not an expert on CUDA but, AFAICT, even in 64-bit CUDA, certain pointers > such as those pointing to shared memory are 32 bit, bec

[clang] [Cuda] Handle -fcuda-short-ptr even with -nocudalib (PR #111682)

frasercrmck wrote: > Seems reasonable, which architectures require this? I know that NVIDIA > deprecated the 32-bit `nvptx` target in CUDA 12 or something. I'm not an expert on CUDA but, AFAICT, even in 64-bit CUDA, certain pointers such as those pointing to shared memory are 32 bit, because t

[clang] [Cuda] Handle -fcuda-short-ptr even with -nocudalib (PR #111682)

https://github.com/jhuber6 approved this pull request. Seems reasonable, which architectures require this? https://github.com/llvm/llvm-project/pull/111682 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/l

[clang] [Cuda] Handle -fcuda-short-ptr even with -nocudalib (PR #111682)

https://github.com/jhuber6 edited https://github.com/llvm/llvm-project/pull/111682 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Cuda] Handle -fcuda-short-ptr even with -nocudalib (PR #111682)

llvmbot wrote: @llvm/pr-subscribers-clang @llvm/pr-subscribers-clang-driver Author: Fraser Cormack (frasercrmck) Changes When padded -nocudalib/-nogpulib, Cuda's argument handling would bail out before handling -fcuda-short-ptr, meaning the frontend and backend data layouts would mismatc

[clang] [Cuda] Handle -fcuda-short-ptr even with -nocudalib (PR #111682)

https://github.com/frasercrmck created https://github.com/llvm/llvm-project/pull/111682 When padded -nocudalib/-nogpulib, Cuda's argument handling would bail out before handling -fcuda-short-ptr, meaning the frontend and backend data layouts would mismatch. >From 67b4b2acf2a54a3a6e2d765714f32