[LLVMdev] [cfe-dev] SPIR Portability Discussion
Micah.Villmow at amd.com
Wed Sep 12 15:40:40 PDT 2012
From: 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; 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>>
> > 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
> > host/device bitness. So this would follow the normal integer
> > 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. I view this case as being well defined in SPIR. It can be produced with something like the following:
%0 = call %spir.size_t @__spir_sizet_convert_size_t(i32 0)
%1 = call %spir.size_t @__spir_sizet_convert_size_t(i32 4)
%2 = call %spir.size_t @__spir_sizet_convert_size_t(i64 8)
%3 = call %spir.size_t @__spir_sizet_neg(%spir.size_t %2)
%4 = call %spir.size_t @__spir_sizet_add(%spir.size_t %1, %spir.size_t %3)
%5 = call %spir.size_t @__spir_sizet_cmp(%spir.size_t %4, %spir.size_t %0)
%6 = call i1 %spir.size_t @__spir_size_t_convert_i1(%spir.size_t %5)
While this is very verbose, it is possible to handle it correctly. Once you lower the SPIR to LLVMIR and run some basic optimizations, then resulting IR should be equivalent as if were generating LLVMIR directly.
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.\
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev