[cfe-dev] [LLVMdev] SPIR Portability Discussion

[Villmow, Micah]

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/cfe-dev/attachments/20120912/bcd8f4be/attachment.html>