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

[Fraser Cormack via cfe-commits]

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 addressable shared memory.
> > > It might be a bit of an intrusive change (albeit a relatively mechanical one), but until we see a GPU come to market that has >4GiB addressable shared memory, I think we should use the "short pointer" datalayout as default
> > 
> > 
> > It also applies to constant and private / local address spaces. I don't think those hit 4 GiB yet but it's more feasible than shared. Making address space 3 32-bit by default would make sense to me.
> 
> I was also considering separating out address space 3 into its own option, yep. At that point I suppose you might as well split out the remaining two, and have `-fcuda-short-ptr` alias the three of them.

@jhuber6 do you have any thoughts on how we'd best split up `-fcuda-short-ptr`? I was initially thinking of `-f[no-]cuda-short-ptr={shared,local,const}` and have the old `-f[no-]cuda-short-ptr` alias "all". However, it seems like this sort of (bitfield toggling on//off) option isn't supported by clang's automated marshalling, and the documented advice is to reconsider the option, rather than do custom marshalling.

It seems as though a comma-joined operation is best marshalled as a list of strings, but having the corresponding "no-" case is pretty rare, and would undoubtedly add extra code and complicate things when trying to tie it in with the old option format.

Maybe we don't need `-fno-cuda-short-ptr=...`, which I think would simplify things here. Of course, I might be thinking about this all wrong, and the frontend and cc1 options could be split up somehow.

https://github.com/llvm/llvm-project/pull/111682