[LLVMdev] SPIR Portability Discussion

[Richard Smith]

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];

struct how_do_you_represent_this_in_IR {
  int a : 1;
  int b : sizeof(void*) * 4;
};

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];

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