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

[Hal Finkel]

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.

 -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