[LLVMdev] SPIR Portability Discussion
boaz.ouriel at intel.com
Wed Sep 12 12:27:25 PDT 2012
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.
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.
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)
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.
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 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 184.108.40.206 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.
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.
More information about the llvm-dev