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

Villmow, Micah Micah.Villmow at amd.com
Thu Aug 30 15:51:07 PDT 2012



> -----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?
> 
> -Eli






More information about the llvm-dev mailing list