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

[Mon Ping Wang]

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