thr3ads.net - llvm dev - [LLVMdev] SPIR Portability Discussion [Sep 2012]

If this information is useful, please help other people find it:
Share via:

Villmow, Micah

2012-Sep-12 21:23 UTC

[LLVMdev] SPIR Portability Discussion

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Richard Smith
Sent: Wednesday, September 12, 2012 1:55 PM
To: Ouriel, Boaz
Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] SPIR Portability Discussion

On Wed, Sep 12, 2012 at 12:27 PM, Ouriel, Boaz <boaz.ouriel at
intel.com<mailto:boaz.ouriel at intel.com>> wrote:
Hey All,

This is a very big topic in SPIR and probably a very controversial one as well.
It includes dealing with 32 vs. 64 bit architectures and OpenCL "C"
endianness.
We have written down some of the aspects, but of course did not cover everything
- let's start a discussion on the portability and see where it takes us.
I suggest we start with the 32 vs. 64 bits discussion and then move to the
Endianness part.

****Introduction****
As a reminder, portability is one of SPIR's goals.
However, SPIR does not attempt to solve inherent portability issues, which exist
in OpenCL "C" or in C99.
It is clear that OpenCL programs could be written in a way which make them non
portable and very device specific.
Such programs will never be portable. In addition, some corner case
scenario's which have been identified by Khronos members have been
disallowed in SPIR.
So, SPIR aims at being portable but not for every scenario.

1) ****Portability between Devices with different address width (32 vs. 64
bits)****
During the design stages, Khronos members needed to decide on its philosophy
when it comes to dealing with the address width of devices (32 vs. 64bits).
During internal discussions, two alternatives came up. The first alternative was
to split SPIR into two sub-cases: SPIR 32bits and SPIR 64bits.
The second alternative was to try and abstract this information at SPIR level.

Splitting SPIR into 32bit and 64bit is simpler to implement. However, it is less
portable.
This will require OpenCL developers to pre-compile two versions of their code
one for 32bit and another for 64bit devices and make their application aware at
runtime to the underlying device architecture.
OpenCL applications would need to load the proper SPIR binary based on the
device architecture.
An option that was raised during the discussions was to have a fat binary that
contains both 32bit and 64bit versions of SPIR binaries.
However, this option was controversial inside Khronos and eventually was not
accepted.
The decision was to pursue the second alternative. Khronos members understand
that this is a more complex alternative and does not guarantee 100% percent
coverage to all cases.
However, as stated before, SPIR attempts to solve the important cases. Those
particular cases which SPIR will not be able to address are explicitly
documented in the specification.

         ****Pointers****
During SPIR generation, the size, and the alignment of pointers is unknown (32
vs. 64 bits).
The SPIR representation shouldn't assume anything about the size and the
alignment of pointers,
but it might use pointers in the usual way (except from using GEP when the
pointed type has unknown size - this one is illegal in SPIR and will fail the
SPIR verification pass which was written by Khronos members)

         *****Sizeof******
Most valid built-in and user specific types in OpenCL have known non
device-specific size.
However, for some types (pointers, size_t, ptrdiff_t) the size is unknown during
compilation.
To overcome this issue, SPIR provides functions to substitute the constant
values of the sizeof operator.
These functions should be resolved by the device backend compiler when producing
the final machine code of the OpenCL program.

OpenCL 1.2 (6.3)/k says the result of sizeof is an ICE. So these are valid:

int does_this_compile[sizeof(void*) - 3];
[Villmow, Micah] 'ICE'? Integer compile time expression? While not
pretty, this can be represented in SPIR with the following sequence on
instructions
%1 = call %spir.size_t @__spir_sizet_convert_size_t(i32 3)
%2 = call %spir.size_t @__spir_size_of_sizet()
%3 = call %spir.size_t @__spir_sizet_sub(%spir.size_t %1, %spir.size_t %2)
%4 = call %spir.size_t @__spir_sizet_convert_i32(%spir.size_t %3)
%5 = alloca i32, i32 %4

struct how_do_you_represent_this_in_IR {
  int a : 1;
  int b : sizeof(void*) * 4;
};
[Villmow, Micah] Bitfields are illegal in OpenCL (See 6.9.c);

Is OpenCL going to be changed to reject these cases?

How do you perform record layout if the size of a pointer is unknown? For
instance:

struct A {
  int *p;
  int n;
} a;
int arr[offsetof(A, n) - 3]; // or, int arr[(char*)&a.n - (char*)&a.p -
3];
[Villmow, Micah] Since in the current implementation of SPIR, a pointer is
defined as 64bits when in a structure(SPIR spec 2.1.5), the offsets themselves
are well defined.

-- Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120912/bcd8f4be/attachment.html>

Richard Smith

2012-Sep-12 21:51 UTC

head link

[LLVMdev] SPIR Portability Discussion

On Wed, Sep 12, 2012 at 2:23 PM, Villmow, Micah <Micah.Villmow at
amd.com>wrote:
>  ** **
>
> ** **
>
> *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] *On
> Behalf Of *Richard Smith
> *Sent:* Wednesday, September 12, 2012 1:55 PM
> *To:* Ouriel, Boaz
> *Cc:* cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
> *Subject:* Re: [LLVMdev] SPIR Portability Discussion****
>
> ** **
>
> On Wed, Sep 12, 2012 at 12:27 PM, Ouriel, Boaz <boaz.ouriel at
intel.com>
> wrote:****
>
> Hey All,
>
> This is a very big topic in SPIR and probably a very controversial one as
> well. It includes dealing with 32 vs. 64 bit architectures and OpenCL
"C"
> endianness.
> We have written down some of the aspects, but of course did not cover
> everything - let's start a discussion on the portability and see where
it
> takes us.
> I suggest we start with the 32 vs. 64 bits discussion and then move to the
> Endianness part.
>
> ****Introduction****
> As a reminder, portability is one of SPIR's goals.
> However, SPIR does not attempt to solve inherent portability issues, which
> exist in OpenCL "C" or in C99.
> It is clear that OpenCL programs could be written in a way which make them
> non portable and very device specific.
> Such programs will never be portable. In addition, some corner case
> scenario's which have been identified by Khronos members have been
> disallowed in SPIR.
> So, SPIR aims at being portable but not for every scenario.
>
> 1) ****Portability between Devices with different address width (32 vs. 64
> bits)****
> During the design stages, Khronos members needed to decide on its
> philosophy when it comes to dealing with the address width of devices (32
> vs. 64bits).
> During internal discussions, two alternatives came up. The first
> alternative was to split SPIR into two sub-cases: SPIR 32bits and SPIR
> 64bits.
> The second alternative was to try and abstract this information at SPIR
> level.
>
> Splitting SPIR into 32bit and 64bit is simpler to implement. However, it
> is less portable.
> This will require OpenCL developers to pre-compile two versions of their
> code one for 32bit and another for 64bit devices and make their application
> aware at runtime to the underlying device architecture.
> OpenCL applications would need to load the proper SPIR binary based on the
> device architecture.
> An option that was raised during the discussions was to have a fat binary
> that contains both 32bit and 64bit versions of SPIR binaries.
> However, this option was controversial inside Khronos and eventually was
> not accepted.
> The decision was to pursue the second alternative. Khronos members
> understand that this is a more complex alternative and does not guarantee
> 100% percent coverage to all cases.
> However, as stated before, SPIR attempts to solve the important cases.
> Those particular cases which SPIR will not be able to address are
> explicitly documented in the specification.
>
>          ****Pointers****
> During SPIR generation, the size, and the alignment of pointers is unknown
> (32 vs. 64 bits).
> The SPIR representation shouldn't assume anything about the size and
the
> alignment of pointers,
> but it might use pointers in the usual way (except from using GEP when the
> pointed type has unknown size - this one is illegal in SPIR and will fail
> the SPIR verification pass which was written by Khronos members)
>
>          *****Sizeof******
> Most valid built-in and user specific types in OpenCL have known non
> device-specific size.
> However, for some types (pointers, size_t, ptrdiff_t) the size is unknown
> during compilation.
> To overcome this issue, SPIR provides functions to substitute the constant
> values of the sizeof operator.
> These functions should be resolved by the device backend compiler when
> producing the final machine code of the OpenCL program.****
>
>  ** **
>
> OpenCL 1.2 (6.3)/k says the result of sizeof is an ICE. So these are valid:
> ****
>
> ** **
>
> int does_this_compile[sizeof(void*) - 3];
>
Oops, I meant sizeof(void*) - 5.

> ****
>
> *[Villmow, Micah] ‘ICE’? Integer compile time expression? While not
> pretty, this can be represented in SPIR with the following sequence on
> instructions*
>
> *%1 = call %spir.size_t @__spir_sizet_convert_size_t(i32 3)*
>
> *%2 = call %spir.size_t @__spir_size_of_sizet()*
>
> *%3 = call %spir.size_t @__spir_sizet_sub(%spir.size_t %1, %spir.size_t
> %2)*
>
> *%4 = call %spir.size_t @__spir_sizet_convert_i32(%spir.size_t %3)*
>
> *%5 = alloca i32, i32 %4*
>
My point here was that if sizeof(void*) is an integer constant expression,
then this code has a constraint violation if sizeof(void*) is 4 but not if
sizeof(void*) is 8 (and my example was intended to be of a global array,
not a function-local one, so you can't fall back to treating it as a VLA).
Another case which might depend on this:

enum E {
  a = sizeof(void*) // is this valid?
};

Based on the behavior you describe above, it looks like sizeof applied to a
pointer (and to size_t etc.) isn't a constant expression in SPIR's
model.


Another factor to consider, with size_t etc as defined in SPIR, is the
usual arithmetic conversions. For instance (assuming a 64-bit long long),
sizeof(int) + 1LL would be signed if size_t is 32 bits wide, and would be
unsigned if size_t is 64 bits wide. How is this handled?

> How do you perform record layout if the size of a pointer is unknown? For
> instance:
>
> **
>
> ** **
>
> struct A {****
>
>   int *p;****
>
>   int n;****
>
> } a;****
>
> int arr[offsetof(A, n) - 3]; // or, int arr[(char*)&a.n -
(char*)&a.p - 3];
> ****
>
> *[Villmow, Micah] Since in the current implementation of SPIR, a pointer
> is defined as 64bits when in a structure(SPIR spec 2.1.5), the offsets
> themselves are well defined.*
>
I see, that makes sense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120912/06aadc50/attachment.html>

Villmow, Micah

2012-Sep-12 21:58 UTC

head link

[LLVMdev] SPIR Portability Discussion

From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of Richard
Smith
Sent: Wednesday, September 12, 2012 2:51 PM
To: Villmow, Micah
Cc: Ouriel, Boaz; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] SPIR Portability Discussion

On Wed, Sep 12, 2012 at 2:23 PM, Villmow, Micah <Micah.Villmow at
amd.com<mailto:Micah.Villmow at amd.com>> wrote:

From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at
cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces
at cs.uiuc.edu>] On Behalf Of Richard Smith
Sent: Wednesday, September 12, 2012 1:55 PM
To: Ouriel, Boaz
Cc: cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>; llvmdev at
cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] SPIR Portability Discussion

On Wed, Sep 12, 2012 at 12:27 PM, Ouriel, Boaz <boaz.ouriel at
intel.com<mailto:boaz.ouriel at intel.com>> wrote:
Hey All,

This is a very big topic in SPIR and probably a very controversial one as well.
It includes dealing with 32 vs. 64 bit architectures and OpenCL "C"
endianness.
We have written down some of the aspects, but of course did not cover everything
- let's start a discussion on the portability and see where it takes us.
I suggest we start with the 32 vs. 64 bits discussion and then move to the
Endianness part.

****Introduction****
As a reminder, portability is one of SPIR's goals.
However, SPIR does not attempt to solve inherent portability issues, which exist
in OpenCL "C" or in C99.
It is clear that OpenCL programs could be written in a way which make them non
portable and very device specific.
Such programs will never be portable. In addition, some corner case
scenario's which have been identified by Khronos members have been
disallowed in SPIR.
So, SPIR aims at being portable but not for every scenario.

1) ****Portability between Devices with different address width (32 vs. 64
bits)****
During the design stages, Khronos members needed to decide on its philosophy
when it comes to dealing with the address width of devices (32 vs. 64bits).
During internal discussions, two alternatives came up. The first alternative was
to split SPIR into two sub-cases: SPIR 32bits and SPIR 64bits.
The second alternative was to try and abstract this information at SPIR level.

Splitting SPIR into 32bit and 64bit is simpler to implement. However, it is less
portable.
This will require OpenCL developers to pre-compile two versions of their code
one for 32bit and another for 64bit devices and make their application aware at
runtime to the underlying device architecture.
OpenCL applications would need to load the proper SPIR binary based on the
device architecture.
An option that was raised during the discussions was to have a fat binary that
contains both 32bit and 64bit versions of SPIR binaries.
However, this option was controversial inside Khronos and eventually was not
accepted.
The decision was to pursue the second alternative. Khronos members understand
that this is a more complex alternative and does not guarantee 100% percent
coverage to all cases.
However, as stated before, SPIR attempts to solve the important cases. Those
particular cases which SPIR will not be able to address are explicitly
documented in the specification.

         ****Pointers****
During SPIR generation, the size, and the alignment of pointers is unknown (32
vs. 64 bits).
The SPIR representation shouldn't assume anything about the size and the
alignment of pointers,
but it might use pointers in the usual way (except from using GEP when the
pointed type has unknown size - this one is illegal in SPIR and will fail the
SPIR verification pass which was written by Khronos members)

         *****Sizeof******
Most valid built-in and user specific types in OpenCL have known non
device-specific size.
However, for some types (pointers, size_t, ptrdiff_t) the size is unknown during
compilation.
To overcome this issue, SPIR provides functions to substitute the constant
values of the sizeof operator.
These functions should be resolved by the device backend compiler when producing
the final machine code of the OpenCL program.

OpenCL 1.2 (6.3)/k says the result of sizeof is an ICE. So these are valid:

int does_this_compile[sizeof(void*) - 3];

Oops, I meant sizeof(void*) - 5.

[Villmow, Micah] 'ICE'? Integer compile time expression? While not
pretty, this can be represented in SPIR with the following sequence on
instructions
%1 = call %spir.size_t @__spir_sizet_convert_size_t(i32 3)
%2 = call %spir.size_t @__spir_size_of_sizet()
%3 = call %spir.size_t @__spir_sizet_sub(%spir.size_t %1, %spir.size_t %2)
%4 = call %spir.size_t @__spir_sizet_convert_i32(%spir.size_t %3)
%5 = alloca i32, i32 %4

My point here was that if sizeof(void*) is an integer constant expression, then
this code has a constraint violation if sizeof(void*) is 4 but not if
sizeof(void*) is 8 (and my example was intended to be of a global array, not a
function-local one, so you can't fall back to treating it as a VLA).
[Villmow, Micah] OpenCL restricts this behavior, so it is illegal.
Another case which might depend on this:

enum E {
  a = sizeof(void*) // is this valid?
};
[Villmow, Micah] I will have to think on this one, good example.

Based on the behavior you describe above, it looks like sizeof applied to a
pointer (and to size_t etc.) isn't a constant expression in SPIR's
model.

Another factor to consider, with size_t etc as defined in SPIR, is the usual
arithmetic conversions. For instance (assuming a 64-bit long long), sizeof(int)
+ 1LL would be signed if size_t is 32 bits wide, and would be unsigned if size_t
is 64 bits wide. How is this handled?
[Villmow, Micah] OpenCL C defines 'int' to be 32bits irrespective of the
host/device bitness. So this would follow the normal integer promotion rules.

How do you perform record layout if the size of a pointer is unknown? For
instance:

struct A {
  int *p;
  int n;
} a;
int arr[offsetof(A, n) - 3]; // or, int arr[(char*)&a.n - (char*)&a.p -
3];
[Villmow, Micah] Since in the current implementation of SPIR, a pointer is
defined as 64bits when in a structure(SPIR spec 2.1.5), the offsets themselves
are well defined.

I see, that makes sense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120912/810ec6bc/attachment.html>

Possibly Parallel Threads

Search for more seemingly similar threads

llvm dev - Sep 2012 - [LLVMdev] SPIR Portability Discussion

[LLVMdev] SPIR Portability Discussion

[LLVMdev] SPIR Portability Discussion

[LLVMdev] SPIR Portability Discussion

Possibly Parallel Threads