llvm dev - Sep 2012 - [LLVMdev] Proposal: New IR instruction for casting between address spaces

> -----Original Message-----
> From: Dan Gohman [mailto:gohman at apple.com]
> Sent: Tuesday, September 11, 2012 1:28 PM
> To: Villmow, Micah
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Proposal: New IR instruction for casting between
> address spaces
> 
> On Sep 11, 2012, at 1:03 PM, "Villmow, Micah" <Micah.Villmow
at amd.com>
> wrote:
> 
> >
> > From: Villmow, Micah
> > Sent: Tuesday, September 11, 2012 12:51 PM
> > To: llvm-commits at cs.uiuc.edu
> > Subject: Proposal: New IR instruction for casting between address
> > spaces
> >
> > Problem:
> > Bit casting between pointers of different address spaces only works if
> all address space pointers are the same size. With changes from email
> chain [1][2], support for different pointer sizes breaks the bitcast
> instruction since there is no guarantee that the pointer size for the
> address space is on the source and destination arguments are of the same
> size.
> 
> Can you comment on whether the need for this seems like a fundamental
> need, in your field, or more of a limitation of the current generation
> of architectures?
[Villmow, Micah] I think this is a little of both. While the current and
previous generation of GPU architectures are limited in what they are capable of
doing based on hardware restrictions, I also think there is a fundamental need.
Not all devices will run with 64bit operations at full speed(or even have native
instructions in any case), but memory sizes will soon eclipse what is
addressable with 32bit pointers on non-PC systems. What this is causing is 32bit
systems requiring addressing into 64bit memory and switching over to 64bit for
address calculations destroys the performance advantage that the segmented
memory provides.
In the CPU world, this isn't that much of a problem that I can tell as they
have already been solved(32bit vs 64bit math is 1-1 in most cases), but in
non-CPU architectures, this is a huge performance penalty(64bit mul runs 6x
slower than 32bit mul). So being able to switch to 32bit in the cases where it
is required and switch to 64bit where it is required is a fundamental need that
I don't think will go away even if the architectures improve their memory
infrastructure.
> 
> > Solution:
> > Remove the ability of bitcast to cast between pointers of different
> address spaces and replace with an instruction that handles this case
> explicitely.
> >
> > Proposed changes:
> > *         Add restriction to the verifier on the bitcast instruction
> making bitcasting between address spaces illegal.
> > *         Change documentation[3] to state the bitcast to pointers of
> different address spaces is illegal.
> > *         Add in a new IR node, addrspacecast, that allows conversions
> between address spaces
> > *         Updated the reader/writer to handle these cases
> > *         Update the documentation to insert the new IR node.
> > *         Add the following documentation:
> > 'addrspacecast .. to' Instruction
> >
> > Syntax:
> >
> >   <result> = addrspacecast <ty> <value> to
<ty2>             ; yields
> ty2
> > Overview:
> >
> > The ' addrspacecast ' instruction converts value to type ty2
without
> changing any bits.
> 
> This is mildly imprecise, because the whole point of this instruction is
> that it can change the bit width.
[Villmow, Micah] Doh, cut and paste error, will fix it.
> 
> >
> > Arguments:
> >
> > The ' addrspacecast ' instruction takes a value to cast, which
must be
> a non-aggregate first class value with a pointer type, and a type to
> cast it to, which must also be a pointer type. The pointer types of
> value and the destination type, ty2, must be identical, except for the
> address space.
> 
> Having a "pointer type" is sufficient to imply that it is a
"non-
> aggregate first class value".
> 
> >
> > Semantics:
> >
> > The ' addrspacecast ' instruction converts value to type ty2.
It
> converts the type to the type that is implied by the address space of
> the destination pointer. If the destination pointer is smaller than the
> source pointer, the upper bits are truncated. If the inverse is true,
> the upper bits are sign extended, otherwise the operation is a no-op.
> 
> Why sign-extended? Ptrtoint/inttoptr are zero-extended, and it's
> surprising that addrspacecast would be different from them.
[Villmow, Micah] Take for example a pointer representing a negative pointer
offset into a 16 bit address space, if this is converted to a 64bit address
space, the upper 48 bits would be zero and your negative offset just became
positive. The difference between these two instruction types is that
addrspacecast does not explicitly convert to any size, only implicitly, so the
bits would need to be filled correctly.
> 
> Dan
>

Hi,

On Sep 11, 2012, at 2:30 PM, Villmow, Micah wrote:
> 
> 
>> -----Original Message-----
>> From: Dan Gohman [mailto:gohman at apple.com]
>> Sent: Tuesday, September 11, 2012 1:28 PM
>> To: Villmow, Micah
>> Cc: llvmdev at cs.uiuc.edu
>> Subject: Re: [LLVMdev] Proposal: New IR instruction for casting between
>> address spaces
>> 
>> On Sep 11, 2012, at 1:03 PM, "Villmow, Micah"
<Micah.Villmow at amd.com>
>> wrote:
>> 
>>> 
>>> From: Villmow, Micah
>>> Sent: Tuesday, September 11, 2012 12:51 PM
>>> To: llvm-commits at cs.uiuc.edu
>>> Subject: Proposal: New IR instruction for casting between address
>>> spaces
>>> 
>>> Problem:
>>> Bit casting between pointers of different address spaces only works
if
>> all address space pointers are the same size. With changes from email
>> chain [1][2], support for different pointer sizes breaks the bitcast
>> instruction since there is no guarantee that the pointer size for the
>> address space is on the source and destination arguments are of the
same
>> size.
>> 
>> Can you comment on whether the need for this seems like a fundamental
>> need, in your field, or more of a limitation of the current generation
>> of architectures?
> [Villmow, Micah] I think this is a little of both. While the current and
previous generation of GPU architectures are limited in what they are capable of
doing based on hardware restrictions, I also think there is a fundamental need.
Not all devices will run with 64bit operations at full speed(or even have native
instructions in any case), but memory sizes will soon eclipse what is
addressable with 32bit pointers on non-PC systems. What this is causing is 32bit
systems requiring addressing into 64bit memory and switching over to 64bit for
address calculations destroys the performance advantage that the segmented
memory provides.
> In the CPU world, this isn't that much of a problem that I can tell as
they have already been solved(32bit vs 64bit math is 1-1 in most cases), but in
non-CPU architectures, this is a huge performance penalty(64bit mul runs 6x
slower than 32bit mul). So being able to switch to 32bit in the cases where it
is required and switch to 64bit where it is required is a fundamental need that
I don't think will go away even if the architectures improve their memory
infrastructure.
>> 
>>> Solution:
>>> Remove the ability of bitcast to cast between pointers of different
>> address spaces and replace with an instruction that handles this case
>> explicitely.
>>> 
>>> Proposed changes:
>>> *         Add restriction to the verifier on the bitcast
instruction
>> making bitcasting between address spaces illegal.
>>> *         Change documentation[3] to state the bitcast to pointers
of
>> different address spaces is illegal.
>>> *         Add in a new IR node, addrspacecast, that allows
conversions
>> between address spaces
>>> *         Updated the reader/writer to handle these cases
>>> *         Update the documentation to insert the new IR node.
>>> *         Add the following documentation:
>>> 'addrspacecast .. to' Instruction
>>> 
>>> Syntax:
>>> 
>>>  <result> = addrspacecast <ty> <value> to
<ty2>             ; yields
>> ty2
>>> Overview:
>>> 
>>> The ' addrspacecast ' instruction converts value to type
ty2 without
>> changing any bits.
>> 
>> This is mildly imprecise, because the whole point of this instruction
is
>> that it can change the bit width.
> [Villmow, Micah] Doh, cut and paste error, will fix it.
>> 
>>> 
>>> Arguments:
>>> 
>>> The ' addrspacecast ' instruction takes a value to cast,
which must be
>> a non-aggregate first class value with a pointer type, and a type to
>> cast it to, which must also be a pointer type. The pointer types of
>> value and the destination type, ty2, must be identical, except for the
>> address space.
>> 
>> Having a "pointer type" is sufficient to imply that it is a
"non-
>> aggregate first class value".
>> 
>>> 
>>> Semantics:
>>> 
>>> The ' addrspacecast ' instruction converts value to type
ty2. It
>> converts the type to the type that is implied by the address space of
>> the destination pointer. If the destination pointer is smaller than the
>> source pointer, the upper bits are truncated. If the inverse is true,
>> the upper bits are sign extended, otherwise the operation is a no-op.
>> 
>> Why sign-extended? Ptrtoint/inttoptr are zero-extended, and it's
>> surprising that addrspacecast would be different from them.
> [Villmow, Micah] Take for example a pointer representing a negative pointer
offset into a 16 bit address space, if this is converted to a 64bit address
space, the upper 48 bits would be zero and your negative offset just became
positive. The difference between these two instruction types is that
addrspacecast does not explicitly convert to any size, only implicitly, so the
bits would need to be filled correctly.
>> 
I view a pointer as pointing to a location in memory and not as an offset
relative to some base register.  I think the proper semantic here is the same as
inttoptr where it does a zero-extension.

  -- Mon Ping



>> Dan
>> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

> -----Original Message-----
> From: Mon P Wang [mailto:monping at apple.com]
> Sent: Wednesday, September 12, 2012 1:12 PM
> To: Villmow, Micah
> Cc: Dan Gohman; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Proposal: New IR instruction for casting between
> address spaces
> 
> Hi,
> 
> On Sep 11, 2012, at 2:30 PM, Villmow, Micah wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Dan Gohman [mailto:gohman at apple.com]
> >> Sent: Tuesday, September 11, 2012 1:28 PM
> >> To: Villmow, Micah
> >> Cc: llvmdev at cs.uiuc.edu
> >> Subject: Re: [LLVMdev] Proposal: New IR instruction for casting
> between
> >> address spaces
> >>
> >> On Sep 11, 2012, at 1:03 PM, "Villmow, Micah"
> <Micah.Villmow at amd.com>
> >> wrote:
> >>
> >>>
> >>> From: Villmow, Micah
> >>> Sent: Tuesday, September 11, 2012 12:51 PM
> >>> To: llvm-commits at cs.uiuc.edu
> >>> Subject: Proposal: New IR instruction for casting between
address
> >>> spaces
> >>>
> >>> Problem:
> >>> Bit casting between pointers of different address spaces only
works
> if
> >> all address space pointers are the same size. With changes from
> email
> >> chain [1][2], support for different pointer sizes breaks the
bitcast
> >> instruction since there is no guarantee that the pointer size for
> the
> >> address space is on the source and destination arguments are of
the
> same
> >> size.
> >>
> >> Can you comment on whether the need for this seems like a
> fundamental
> >> need, in your field, or more of a limitation of the current
> generation
> >> of architectures?
> > [Villmow, Micah] I think this is a little of both. While the current
> and previous generation of GPU architectures are limited in what they
> are capable of doing based on hardware restrictions, I also think there
> is a fundamental need. Not all devices will run with 64bit operations
> at full speed(or even have native instructions in any case), but memory
> sizes will soon eclipse what is addressable with 32bit pointers on non-
> PC systems. What this is causing is 32bit systems requiring addressing
> into 64bit memory and switching over to 64bit for address calculations
> destroys the performance advantage that the segmented memory provides.
> > In the CPU world, this isn't that much of a problem that I can
tell
> as they have already been solved(32bit vs 64bit math is 1-1 in most
> cases), but in non-CPU architectures, this is a huge performance
> penalty(64bit mul runs 6x slower than 32bit mul). So being able to
> switch to 32bit in the cases where it is required and switch to 64bit
> where it is required is a fundamental need that I don't think will go
> away even if the architectures improve their memory infrastructure.
> >>
> >>> Solution:
> >>> Remove the ability of bitcast to cast between pointers of
different
> >> address spaces and replace with an instruction that handles this
> case
> >> explicitely.
> >>>
> >>> Proposed changes:
> >>> *         Add restriction to the verifier on the bitcast
> instruction
> >> making bitcasting between address spaces illegal.
> >>> *         Change documentation[3] to state the bitcast to
pointers
> of
> >> different address spaces is illegal.
> >>> *         Add in a new IR node, addrspacecast, that allows
> conversions
> >> between address spaces
> >>> *         Updated the reader/writer to handle these cases
> >>> *         Update the documentation to insert the new IR node.
> >>> *         Add the following documentation:
> >>> 'addrspacecast .. to' Instruction
> >>>
> >>> Syntax:
> >>>
> >>>  <result> = addrspacecast <ty> <value> to
<ty2>             ;
> yields
> >> ty2
> >>> Overview:
> >>>
> >>> The ' addrspacecast ' instruction converts value to
type ty2
> without
> >> changing any bits.
> >>
> >> This is mildly imprecise, because the whole point of this
> instruction is
> >> that it can change the bit width.
> > [Villmow, Micah] Doh, cut and paste error, will fix it.
> >>
> >>>
> >>> Arguments:
> >>>
> >>> The ' addrspacecast ' instruction takes a value to
cast, which must
> be
> >> a non-aggregate first class value with a pointer type, and a type
to
> >> cast it to, which must also be a pointer type. The pointer types
of
> >> value and the destination type, ty2, must be identical, except for
> the
> >> address space.
> >>
> >> Having a "pointer type" is sufficient to imply that it
is a "non-
> >> aggregate first class value".
> >>
> >>>
> >>> Semantics:
> >>>
> >>> The ' addrspacecast ' instruction converts value to
type ty2. It
> >> converts the type to the type that is implied by the address space
> of
> >> the destination pointer. If the destination pointer is smaller
than
> the
> >> source pointer, the upper bits are truncated. If the inverse is
> true,
> >> the upper bits are sign extended, otherwise the operation is a no-
> op.
> >>
> >> Why sign-extended? Ptrtoint/inttoptr are zero-extended, and
it's
> >> surprising that addrspacecast would be different from them.
> > [Villmow, Micah] Take for example a pointer representing a negative
> pointer offset into a 16 bit address space, if this is converted to a
> 64bit address space, the upper 48 bits would be zero and your negative
> offset just became positive. The difference between these two
> instruction types is that addrspacecast does not explicitly convert to
> any size, only implicitly, so the bits would need to be filled
> correctly.
> >>
> 
> I view a pointer as pointing to a location in memory and not as an
> offset relative to some base register.  I think the proper semantic
> here is the same as inttoptr where it does a zero-extension.
[Villmow, Micah] Yeah, but the pointer won't point to the same location if
the conversion from a smaller pointer to a larger pointer is zero extended.
Take two address spaces(1 and 2) that are 16 and 64 bits in size.
int(1) *a = 0xFFFFFFF9;
int(2) *b = *a;
Is b -10(SExt), or is it 4294967289(ZExt)?
This works for inttoptr and ptrtoint because there is an assumption that the
pointer is always the same size. Maybe we even need to extend ptrtoint/inttoptr
to handle this case by adding unsigned versions?
> 
>   -- Mon Ping
> 
> 
> 
> 
> >> Dan
> >>
> >
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>