[cfe-dev] [LLVMdev] SPIR Portability Discussion

[Villmow, Micah]

Ok, thanks for pointing out the location in the spec. There are some good points here, especially in the rank of 'size_t' that the SPIR WG will have to decide.

However, one thing to keep in mind, this code is by definition non-portable and so SPIR is not trying to make it more portable. This might be one of those cases where implementation defined behavior of C does not allow the program to be portable.

Thanks.

From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of Richard Smith
Sent: Wednesday, September 12, 2012 4:03 PM
To: Villmow, Micah
Cc: Eli Friedman; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
Subject: Re: [cfe-dev] [LLVMdev] SPIR Portability Discussion

On Wed, Sep 12, 2012 at 3:40 PM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote:


From: metafoo at gmail.com<mailto:metafoo at gmail.com> [mailto:metafoo at gmail.com<mailto:metafoo at gmail.com>] On Behalf Of Richard Smith
Sent: Wednesday, September 12, 2012 3:30 PM
To: Villmow, Micah
Cc: Eli Friedman; cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>; llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>

Subject: Re: [cfe-dev] [LLVMdev] SPIR Portability Discussion

On Wed, Sep 12, 2012 at 3:26 PM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote:


> -----Original Message-----
> From: Eli Friedman [mailto:eli.friedman at gmail.com<mailto:eli.friedman at gmail.com>]
> Sent: Wednesday, September 12, 2012 3:22 PM
> To: Villmow, Micah
> Cc: Richard Smith; cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>; llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
> Subject: Re: [cfe-dev] [LLVMdev] SPIR Portability Discussion
>
> On Wed, Sep 12, 2012 at 2:58 PM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>>
> wrote:
> > Another factor to consider, with size_t etc as defined in SPIR, is
> the usual
> > arithmetic conversions. For instance (assuming a 64-bit long long),
> > sizeof(int) + 1LL would be signed if size_t is 32 bits wide, and
> would be
> > unsigned if size_t is 64 bits wide. How is this handled?
> >
> > [Villmow, Micah] OpenCL C defines 'int' to be 32bits irrespective of
> the
> > host/device bitness. So this would follow the normal integer
> promotion
> > rules.
>
> I think you're misunderstanding the issue: the point is, is
> "sizeof(int) + -8LL < 0" true or false?
[Villmow, Micah] Yep, I don't see why this is any different than "4 + -8LL < 0".  OpenCL C, and in turn SPIR, defines sizeof(int) == 4. While this might be a problem in C, this isn't an issue in OpenCL since there is no variance in the sizeof(int) across devices.

I think you're still misunderstanding. If size_t is 32 bits, sizeof(int) + -8LL is -4LL, so the comparison produces true. If it's 64 bits, the -8LL promotes to an unsigned long long, sizeof(int) + -8LL is 18446744073709551612ULL, the 0 promotes to 0ULL, and the comparison produces false.
[Villmow, Micah] I see now, I think you had a type-o in the previous email, "sizeof(sizeof(int))" should have been size_t(sizeof(int)), which was throwing me off.

What I wrote was what I meant. The *value* of sizeof(int) is not relevant here, what matters is the precision of its type (or more specifically, its integer conversion rank).

Though I'm curious where it states we have to promote -8LL to unsigned long and not signed long, I would have thought it would be signed.\

C99 6.3.1.8/1<http://6.3.1.8/1>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120912/8ac14210/attachment.html>