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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to