[LLVMdev] [cfe-dev] SPIR Portability Discussion
richard at metafoo.co.uk
Wed Sep 12 15:30:12 PDT 2012
On Wed, Sep 12, 2012 at 3:26 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote:
> > -----Original Message-----
> > From: Eli Friedman [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; 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>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev