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

[Sumesh Udayakumaran]

Given LLVMs current constraints and lack of fundamental type for
samplers, I think as well that sampler as opaque type makes for much
cleaner representation than as integers. If represented as i32, the
only way to deduce its a sampler is based on its use and thats risky -
consider situations like
    - Sampler is unused - but you still need to preserve the info
    - Compiled at O0. You have to go through stack accesses to know its type

I feel the need for optimizations is barely there for samplers and so
we need to consider the representation issue first.

thanks
Sumesh

On Tue, Oct 16, 2012 at 8:17 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
> Mon Ping,
>  I think you are misunderstanding the point of SPIR. Backends themselves should not be handling SPIR. SPIR should be lowered to valid LLVMIR for your platform, and then optimizations can be applied to the resulting LLVMIR. It is in this loading that you can convert from spir.sampler_t into an i32 and then constant propagation will work just like normal. One reason why sampler_t is an opaque type is that different vendors have different implementations and some do not want their implementations to be a i32, but want to represent it closer to their hardware.
>
> Micah
>
>> -----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: Monday, October 15, 2012 9:58 PM
>> 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
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev