[cfe-dev] OpenCL & SPIR specific types - proposal and patch

[Mon Ping Wang]

Hi,


On Oct 16, 2012, at 7:38 AM, "Ouriel, Boaz" <boaz.ouriel at intel.com> wrote:

> Hi All,
> 
> Thank you for a very good discussion. Clearly we are still not in agreement on the way OpenCL samplers are represented in LLVM IR.
> I think we have a consensus on the rest of the patch, and I agree with Tanya & Mon Ping that there is no reason to postpone the rest of the patch and the patches that rely on it.
> Guy will submit a new patch which includes everything that was included in the previous patch but preserves the i32 data type for samplers. 
> This patch will also demonstrate how easy it is to switch between the 2 versions (opaque vs. i32)
> 
> And now a little about the samplers discussion itself.
> Samplers are not integers, they are just initialized by a 32 bit integer and hence, can't be represented as i32. What clang does today - is a device specific interpretation of what this type really is.
> Our goal is to make clang a sample OpenCL backend that demonstrates how an OpenCL frontend should be implemented.
> 
> As per constant propagation, one can always run this optimization in the backend and achieve the same thing once this type is lowered to i32. I agree that, OpenCL backends will need to support initialization functions. 
> If we want to change this we should work on changing the OpenCL specification first.

Thanks for clarification here.  I don't think there is anything in the OpenCL specification to change for either using a pointer or a 32b value.  The specification doesn't mandate an implementation of sampler_t so it can be a pointer to opaque type, a structure, a class, or a 32b integer. It only requires that the sampler can be initialized using 32b values.

It seems to me that the 32b sampler value encapsulate what is necessary and then a backend can easily replace it  with a target defined object.   As you note above, it is easy to switch between the two.  I don't view the 32b sampler as device specific as it just encapsulate the value in OpenCL C program. I expect most targets will convert the sampler value into something device specific that may or may not be a pointer to some class.   I not sure  why clang would want to represent the opaque object early and not wait for a target specific pass to transform the sampler to what the hardware needs.

  -- Mon Ping


> Thanks for the patience,
> Boaz
> 
> -----Original Message-----
> From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Mon Ping Wang
> Sent: Tuesday, October 16, 2012 06:58
> To: Anton.Lokhmotov at arm.com
> Cc: cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] OpenCL & SPIR specific types - proposal and patch
> 
> Hi,
> 
> I would usually phrase it the other way around.  If we can't apply a standard optimization, I would like to know the reason why that optimization should be illegal.  
> 
> For this particular case, I don't understand why constant propagation shouldn't work.  For example, constant propagation forwards the value to a read image.  For my particular target, I look at the sampler value and image at read image and generate the appropriate code instead of going to the original definition and determine what the sampler is before code generation.
> 
> Another way of stating the issue is that by creating a pointer to an opaque object for sampler, a backend will be forced to support a special initialization function.  If for my target that is unnecessary, I forced to put in support for an initialization function that I do not need.  At the CL language level, program samplers are initialized using a 32b value so it seems more natural to me to match the CL language in this way instead of creating an opaque object.  If for a target, one wants to create an opaque object, it can go through the IR and replace samplers with the opaque object appropriate for that target.
> 
>  -- Mon Ping
> 
> 
> 
> 
> 
> On Oct 15, 2012, at 1:33 AM, Anton Lokhmotov <Anton.Lokhmotov at arm.com> wrote:
> 
>>>> For example, I don't quite understand why constant propagation 
>>>> on samplers should even work.
>>> Sorry, can you please explain why constant propagation shouldn't 
>>> work on program scope samplers?
>> Feel free to enlighten me with an example.  (Perhaps we do it in the
>> backend, but I'm unaware of the need to do it at the LLVM-IR level.)
>> 
>> Thanks,
>> Anton.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev