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

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

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