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>>
> 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. 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.\
Thanks, Micah
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120912/0537c023/attachment.html>