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

[Eli Friedman]

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.)

-Eli