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>
On Wed, Sep 12, 2012 at 3:40 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:> > > > > 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> > 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 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)This conversion simply isn't correct: the type of the comparison is not size_t if size_t is 32 bits. -Eli
On Wed, Sep 12, 2012 at 3:40 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote:> ** ** > > ** ** > > *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> > 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 > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120912/78088b1b/attachment.html>
> -----Original Message----- > From: Eli Friedman [mailto:eli.friedman at gmail.com] > Sent: Wednesday, September 12, 2012 3:50 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 3:40 PM, Villmow, Micah <Micah.Villmow at amd.com> > wrote: > > > > > > > > > > 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> > > 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 > 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) > > This conversion simply isn't correct: the type of the comparison is > not size_t if size_t is 32 bits.[Villmow, Micah] Sorry, the result of sizet_cmp is i1, I should've looked at the spec for correctness. The point I was trying to make is that in both a 32bit system and a 64bit system, the sequence of instructions should still evaluate to the correct result. The difference is that evaluation does not occur in the frontend, but instead occurs once the SPIR binary is loaded and converted to the device binary. All of these function calls should collapse into a single true/false constant after constant propagation has occurred.> > -Eli
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/llvm-dev/attachments/20120912/8ac14210/attachment.html>