> > OpenCL 1.2 (6.3)/k says the result of sizeof is an ICE. So these are valid: > > int does_this_compile[sizeof(void*) - 3]; > > struct how_do_you_represent_this_in_IR { > int a : 1; > int b : sizeof(void*) * 4; > }; > > Is OpenCL going to be changed to reject these cases? >I don't think that they plan to allow it. I am not sure how much value dynamic sized bitfields bring to OpenCL users. In theory they could use opaque types and a number of external functions which can be lowered to legal LLVM-IR once the value of sizeof is known.> How do you perform record layout if the size of a pointer is unknown? For instance: > > struct A { > int *p; > int n; > } a; > int arr[offsetof(A, n) - 3]; // or, int arr[(char*)&a.n - (char*)&a.p - 3]; >They can replace LLVM's alloca with a fake function which can be lowered to a regular alloca once the size is known.> -- Richard > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Nadav Rotem > Sent: Wednesday, September 12, 2012 2:17 PM > To: Richard Smith > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] SPIR Portability Discussion > > > > > OpenCL 1.2 (6.3)/k says the result of sizeof is an ICE. So these are > valid: > > > > int does_this_compile[sizeof(void*) - 3]; > > > > struct how_do_you_represent_this_in_IR { > > int a : 1; > > int b : sizeof(void*) * 4; > > }; > > > > Is OpenCL going to be changed to reject these cases? > > > > I don't think that they plan to allow it. I am not sure how much value > dynamic sized bitfields bring to OpenCL users. > In theory they could use opaque types and a number of external > functions which can be lowered to legal LLVM-IR once the value of > sizeof is known. > > > How do you perform record layout if the size of a pointer is unknown? > For instance: > > > > struct A { > > int *p; > > int n; > > } a; > > int arr[offsetof(A, n) - 3]; // or, int arr[(char*)&a.n - (char*)&a.p > - 3]; > > > > They can replace LLVM's alloca with a fake function which can be > lowered to a regular alloca once the size is known.[Villmow, Micah] Yep, this is the basic idea of the steps taken to make SPIR portable. There is no restriction in the C99 or OpenCL specs that I know of that requires the frontend to make decisions on the size of device specific constructs. While it is the most logical and efficient choice, it cannot be determined if the target device is not known, so the decision is delayed via function calls or opaque types until this information is known, the results are still compile time constants.> > > -- Richard > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Wed, Sep 12, 2012 at 2:30 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:> > >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Nadav Rotem >> Sent: Wednesday, September 12, 2012 2:17 PM >> To: Richard Smith >> Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu >> Subject: Re: [LLVMdev] SPIR Portability Discussion >> >> > >> > OpenCL 1.2 (6.3)/k says the result of sizeof is an ICE. So these are >> valid: >> > >> > int does_this_compile[sizeof(void*) - 3]; >> > >> > struct how_do_you_represent_this_in_IR { >> > int a : 1; >> > int b : sizeof(void*) * 4; >> > }; >> > >> > Is OpenCL going to be changed to reject these cases? >> > >> >> I don't think that they plan to allow it. I am not sure how much value >> dynamic sized bitfields bring to OpenCL users. >> In theory they could use opaque types and a number of external >> functions which can be lowered to legal LLVM-IR once the value of >> sizeof is known. >> >> > How do you perform record layout if the size of a pointer is unknown? >> For instance: >> > >> > struct A { >> > int *p; >> > int n; >> > } a; >> > int arr[offsetof(A, n) - 3]; // or, int arr[(char*)&a.n - (char*)&a.p >> - 3]; >> > >> >> They can replace LLVM's alloca with a fake function which can be >> lowered to a regular alloca once the size is known. > [Villmow, Micah] Yep, this is the basic idea of the steps taken to make SPIR portable. > There is no restriction in the C99 or OpenCL specs that I know of that requires the frontend to make decisions on the size of device specific constructs.Well, if you ignore the preprocessor, it's true that there's no strict requirement....>While it is the most logical and efficient choice, it cannot be determined if the target device is not known, so the decision is delayed via function calls or opaque types until this information is known, the results are still compile time constants.The issue is that it starts to get nasty really fast in the general case: // We're required to diagnose this iff sizeof(size_t) != 4. extern int x[20]; int x[sizeof(size_t) * 5]; // We're required to diagnose this iff sizeof(size_t) == 4. void f(int x) { switch(x) { case 4: case sizeof(size_t): break; } } You basically have to delay lowering anything that can involve an integer constant expression. -Eli