[LLVMdev] [cfe-dev] SPIR Review Status: after Introduction and 32bits vs. 64bits discussions

[Eli Friedman]

On Wed, Sep 19, 2012 at 5:43 AM, Benyei, Guy <guy.benyei at intel.com> wrote:
> Ouriel, Boaz wrote:
>
>
> ...
>
>
> *** Richard Smith, Eli Friedman & Nadav Rotem: Portability Issues ***
>
>          *****comment 1: int does_this_compile[sizeof(void*) - 3];
>                       Answer: We are discussing this internally and will provide an answer soon.
>
>         ****comment 2: struct how_do_you_represent_this_in_IR {
>                                   int a : 1;
>                                   int b : sizeof(void*) * 4;
>                         };
>                          Answer: Bitfields are disallowed in OpenCL “C”
>
>               ****comment 3:  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];
>
>                        Answer:  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.
>
>         *****comment 4:
>                   // We're required to diagnose this iff sizeof(size_t) != 4.
>                  extern int x[20];
>                  int x[sizeof(size_t) * 5;
>                // We're required to diagnose this iff sizeof(size_t) == 4.
>                 void f(int x) {
>                        switch(x) {
>                           case 4:
>                           case sizeof(size_t):
>                                 break;
>                     }
>                }
>               Answer:  We are discussing this an provide an answer soon.
>
>
> [Guy Benyei] Some inherently non-portable code snippets won't be supported in SPIR. IMO, these cases should be detected during compilation (and we don't define anything about compilation in the SPIR spec). Especially, when a given source code should raise compilation error in one architecture, and pass in the other (32/64), the result must be a compilation error.
>
>
>        *****comment 5: What about this case?
>                    enum E {
>                          a = sizeof(void*) // is this valid?
>                    };
>                    Answer: we are discussing this and will provide an answer soon.
>
> [Guy Benyei] Same goes here - this source is not functionally portable.

Okay... how exactly do you plan to detect it?  The only reasonable way
I can think of is banning sizeof(void*) and friends in integer
constant expressions, which will work, but might make existing code
non-SPIR-compatible.

>        ****comment 6: What is  the rank of ‘size_t’?
>                   example: is "sizeof(int) + -8LL < 0" true or false?
>                    Answer: we are discussing this and will provide an answer soon.
>
> [Guy Benyei] We discussed this case a lot, and IMO there are two possible solutions: we can either assign a rank to size_t, s.t. rank(long) < rank(ptrdiff_t) < rank(size_t) < rank(ulong), or we can simply disallow the case where the usual arithmetic conversions should decide between types which would lead to different decision in 64bit and 32bit architectures. Personally I don't really like the option of assigning a rank to size_t, since it would change the behavior in some corner cases, and lead to results that were not expected by the developer.

Banning the conversions is reasonable, and should be straightforward to detect.

-Eli