[LLVMdev] FW: RFC: Supporting different sized address space arithmetic

[Villmow, Micah]

> -----Original Message-----
> From: Hal Finkel [mailto:hfinkel at anl.gov]
> Sent: Thursday, August 30, 2012 4:09 PM
> To: Eli Friedman
> Cc: Villmow, Micah; LLVM Developers Mail
> Subject: Re: [LLVMdev] FW: RFC: Supporting different sized address space
> arithmetic
> 
> On Thu, 30 Aug 2012 15:58:54 -0700
> Eli Friedman <eli.friedman at gmail.com> wrote:
> 
> > On Thu, Aug 30, 2012 at 3:51 PM, Villmow, Micah
> > <Micah.Villmow at amd.com> wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Eli Friedman [mailto:eli.friedman at gmail.com]
> > >> Sent: Thursday, August 30, 2012 3:43 PM
> > >> To: Villmow, Micah
> > >> Cc: LLVM Developers Mail
> > >> Subject: Re: [LLVMdev] FW: RFC: Supporting different sized address
> > >> space arithmetic
> > >>
> > >> On Thu, Aug 30, 2012 at 3:27 PM, Villmow, Micah
> > >> <Micah.Villmow at amd.com> wrote:
> > >> >
> > >> >
> > >> >> -----Original Message-----
> > >> >> From: Eli Friedman [mailto:eli.friedman at gmail.com]
> > >> >> Sent: Thursday, August 30, 2012 3:03 PM
> > >> >> To: Villmow, Micah
> > >> >> Cc: LLVM Developers Mail
> > >> >> Subject: Re: [LLVMdev] FW: RFC: Supporting different sized
> > >> >> address space arithmetic
> > >> >>
> > >> >> On Thu, Aug 30, 2012 at 2:38 PM, Villmow, Micah
> > >> >> <Micah.Villmow at amd.com>
> > >> >> wrote:
> > >> >> > Eli,
> > >> >> >  Here is an updated patch. This is a lot smaller based on your
> > >> >> feedback and still solves the same problem.
> > >> >>
> > >> >> The patch appears to be corrupt; can you regenerate it?
> > >> > [Villmow, Micah] Attached.
> > >> >>
> > >> >> > For your comment on the IR changes, I'm reluctant to introduce
> > >> >> > changes
> > >> >> there because really the backend is overriding the default
> > >> >> behavior at a device specific level. The optimizations
> > >> >> themselves can be dangerous, but still should produce correct
> > >> >> results, this only allows the backend to optimize certain cases
> > >> >> and is opt-in.
> > >> >>
> > >> >> Suppose I have an array of ten pointers into some address-space
> > >> >> which uses 16-bit pointers, and the default pointer size is 64
> > >> >> bits.  How many bytes in memory does that take?  To me, it seems
> > >> >> like the obvious answer is 20 bytes, but if you compute it using
> > >> >> our current TargetData, you'll come up with an answer of 80.
> > >> >> That can't work.
> > >> >>
> > >> >> If your answer is that it should be 80, and the size of a
> > >> >> pointer isn't something the frontend/IR optimizers should be
> > >> >> aware of, I'm not sure your approach makes sense; you could just
> > >> >> introduce custom load/store nodes in your target which truncate
> > >> >> the pointer, and you wouldn't need to mess with the size of a
> > >> >> pointer at all.
> > >> > [Villmow, Micah] Yeah I see your point here. I don't deal with
> > >> > array
> > >> of pointers in OpenCL, so didn't think of this case.
> > >> >
> > >> > So, what about extending data layout to support something like:
> > >> > p#:size:abi:pref <- specify the size, abi and preference for the
> > >> pointer of address space '#'. Default behavior is p:size:abi:pref.
> > >>
> > >> That's fine.
> > >>
> > >> (You'll also need to deal with the fact that LLVM assumes bit casts
> > >> across address-spaces are lossless.)
> > > [Villmow, Micah] Is that something that should be probably be
> > > reconsidered given adding support for variable sized address spaces?
> >
> > My thinking is that we should ban bitcasts which cross address-spaces,
> > and introduce a new instruction to represent them.  (I know it's a lot
> > of work to add a new instruction, but I don't see any good
> > alternative.)
> 
> Out of curiosity, for what are these currently used? Unless you happen
> to know that some aliasing exists, I don't see how bitcasting a pointer
> in one address space to another makes any sense.
[Villmow, Micah] In OpenCL this is explicitely disallowed at the source level, but I could see this being useful for say the X86 backend where you really only have a global address space and other address spaces exist in the source language(i.e. local/constant in OpenCL). I'm not against adding this restriction, but I'm sure others are.
> 
>  -Hal
> 
> >
> > -Eli
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> 
> --
> Hal Finkel
> Postdoctoral Appointee
> Leadership Computing Facility
> Argonne National Laboratory