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

[Ouriel, Boaz]

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 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.