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

[Villmow, Micah]

Eli,
 Here is the first of many patches that adds support for specifying different pointer sizes for different address spaces.
This is only the modifications to TargetData and not all the changes to the backends/optimizers. There should be no functional changes here since the default value is what the current value is.

After this is approved, my goal is the following:
1) Add a few interfaces to various functions that simplify retrieving address space information.
2) Update all of the optimizations to use address space information when querying the pointer type.
3) Update the backends to follow suite
4) Update the clients(clang, etc..) to use the correct API.
5) remove the default arguments so that future users must explicitly specify an address space.

I'm not sure how to add tests for this since no backend uses it yet, but i'll try to figure something out.
Micah
> -----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.)
> 
> -Eli