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

[Benyei, Guy]

-----Original Message-----
From: Eli Friedman [mailto:eli.friedman at gmail.com] 
Sent: Wednesday, September 19, 2012 23:02
To: Benyei, Guy
Cc: Ouriel, Boaz; llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu
Subject: Re: [cfe-dev] SPIR Review Status: after Introduction and 32bits vs. 64bits discussions

...

>
>         *****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.

...

[Guy Benyei] I see no usable way to make sizeof(void*) or sizeof(size_t) compile time constants while creating a portable intermediate representation. You're right, some existing code might be non-SPIR-compatible; however I think that's a reasonable price to pay when using SPIR. Clang has very good capabilities for providing clear and understandable error messages, so in this case the developer would be informed so he could choose a more portable solution.

Thanks
   Guy Benyei
---------------------------------------------------------------------
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.