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

Hi All,

I would like to open up the discussion on the Host and Device Endianness section
of the SPIR portability topic.
Please read below section number 2 and send your comments.

Thanks,
Boaz

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Ouriel, Boaz
Sent: Wednesday, September 12, 2012 22:27
To: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu
Subject: [LLVMdev] SPIR Portability Discussion

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.

         ****size_t*****
SPIR tries to deal with size_t , ptrdiff_t, uintptr_t, intptr_t. Since these
types have device specific size and alignment, their behavior is uncertain
during compilation time.
SPIR represents these types as opaque types, and defines "builtin"
functions to handle them.

          ****structures****
Structures are also a major issue in OpenCL in general, since their layout and
size are compiler specific. To handle this issue, SPIR defines a standard layout
for structures.

2) ****Host and Device Endianness*****
Before diving into the details of how Endianness is dealt in SPIR, an
introduction to Endianness in OpenCL is required.
In a nutshell, OpenCL standard facilitates the means to mark the endianness type
of variables, which reside in global or constant address space memory.
Since such variables reside in global memory they might have conflicting
endianness between the host and the device.
Hence, OpenCL standard facilitates two types of endianness - a
"device" and "host" types.
The "host" type indicates that the variable uses the endianness of the
host processor.
The "device" type indicates that the variable uses the endianness of
the device on which the program will be executed.
The default type is the "device" type. When the user writes down
programs which rely on the endianness of a particular device -
his code becomes incompatible with devices whose endianness differ, and by
definition is non-portable at OpenCL level.

SPIR specification attempts to facilitate the same mechanism that OpenCL does.
Since "device" type is the default, the only type which requires
special handling is "host".
Initially, Khronos members considered the usage of metadata as the preferred
method for achieving this goal.
Every variable that needs to be marked with "host" endianness type
would be associated with a metadata that indicates it.
This approach could work but is not guaranteed to be enforced by the different
LLVM optimization passes since it is a metadata and as such could be disregarded
by optimization passes.
After a few discussions, Khronos members decided that usage of address space
qualifier could achieve the same effect with better support from the different
optimization passes.
For example, a function that accepts an argument with "host" type can
pass this variable as an argument to another function where the argument is not
marked as well with this type.
Finally, this approach was chosen and is now a part of the specification
(described in section 2.8.2.2 of the specification)

3)****Materialization of a SPIR program****
Since device information is abstracted during SPIR generation, the build phase
of SPIR binaries to device binaries includes an additional phase which is called
"materialization" phase.
This phase resolves the abstracted information and "materializes" a
SPIR binary it to a specific device.

Thanks,
Boaz
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Hi Everyone,

Any comments on the Endianness section in SPIR (read  below the section (2) )

Thanks,
Boaz

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Ouriel, Boaz
Sent: Friday, September 14, 2012 17:17
To: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu
Subject: Re: [LLVMdev] SPIR Portability Discussion - Endianess

Hi All,

I would like to open up the discussion on the Host and Device Endianness section
of the SPIR portability topic.
Please read below section number 2 and send your comments.

Thanks,
Boaz

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Ouriel, Boaz
Sent: Wednesday, September 12, 2012 22:27
To: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu
Subject: [LLVMdev] SPIR Portability Discussion

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.

         ****size_t*****
SPIR tries to deal with size_t , ptrdiff_t, uintptr_t, intptr_t. Since these
types have device specific size and alignment, their behavior is uncertain
during compilation time.
SPIR represents these types as opaque types, and defines "builtin"
functions to handle them.

          ****structures****
Structures are also a major issue in OpenCL in general, since their layout and
size are compiler specific. To handle this issue, SPIR defines a standard layout
for structures.

2) ****Host and Device Endianness*****
Before diving into the details of how Endianness is dealt in SPIR, an
introduction to Endianness in OpenCL is required.
In a nutshell, OpenCL standard facilitates the means to mark the endianness type
of variables, which reside in global or constant address space memory.
Since such variables reside in global memory they might have conflicting
endianness between the host and the device.
Hence, OpenCL standard facilitates two types of endianness - a
"device" and "host" types.
The "host" type indicates that the variable uses the endianness of the
host processor.
The "device" type indicates that the variable uses the endianness of
the device on which the program will be executed.
The default type is the "device" type. When the user writes down
programs which rely on the endianness of a particular device -
his code becomes incompatible with devices whose endianness differ, and by
definition is non-portable at OpenCL level.

SPIR specification attempts to facilitate the same mechanism that OpenCL does.
Since "device" type is the default, the only type which requires
special handling is "host".
Initially, Khronos members considered the usage of metadata as the preferred
method for achieving this goal.
Every variable that needs to be marked with "host" endianness type
would be associated with a metadata that indicates it.
This approach could work but is not guaranteed to be enforced by the different
LLVM optimization passes since it is a metadata and as such could be disregarded
by optimization passes.
After a few discussions, Khronos members decided that usage of address space
qualifier could achieve the same effect with better support from the different
optimization passes.
For example, a function that accepts an argument with "host" type can
pass this variable as an argument to another function where the argument is not
marked as well with this type.
Finally, this approach was chosen and is now a part of the specification
(described in section 2.8.2.2 of the specification)

3)****Materialization of a SPIR program****
Since device information is abstracted during SPIR generation, the build phase
of SPIR binaries to device binaries includes an additional phase which is called
"materialization" phase.
This phase resolves the abstracted information and "materializes" a
SPIR binary it to a specific device.

Thanks,
Boaz
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.