llvm dev - Aug 2012 - [LLVMdev] FW: RFC: Supporting different sized address space arithmetic

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

I think I could throw this together and get back to you within a week or so, but
need to look into the code more to see how much work it would be.
Doing it this way might actually remove the need to make some of the changes I
made as it becomes a more of a core LLVM issue and less of a codegen
issue.
> 
> -Eli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: addr_space_variable_pointer.patch
Type: application/octet-stream
Size: 7356 bytes
Desc: addr_space_variable_pointer.patch
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120830/8953464b/attachment.obj>

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

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

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

Doh! hit send too soon, patch attached.
> -----Original Message-----
> From: Villmow, Micah
> Sent: Thursday, September 06, 2012 9:17 AM
> To: 'Eli Friedman'
> Cc: LLVM Developers Mail
> Subject: RE: [LLVMdev] FW: RFC: Supporting different sized address space
> arithmetic
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multiple_pointer_target_data.patch
Type: application/octet-stream
Size: 17181 bytes
Desc: multiple_pointer_target_data.patch
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120906/7c8fa958/attachment.obj>