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

[Mon Ping Wang]

On Oct 17, 2012, at 8:46 AM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote:

> 
> 
>> -----Original Message-----
>> From: Mon Ping Wang [mailto:monping at apple.com]
>> Sent: Tuesday, October 16, 2012 8:35 PM
>> To: Sumesh Udayakumaran
>> Cc: Villmow, Micah; cfe-dev at cs.uiuc.edu; Anton.Lokhmotov at arm.com
>> Subject: Re: [cfe-dev] OpenCL & SPIR specific types - proposal and
>> patch
>> 
>> 
>> On Oct 16, 2012, at 12:03 PM, Sumesh Udayakumaran <sumesh.uk at gmail.com>
>> wrote:
>> 
>>> 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
>>> 
>> 
>> From the previous email on this thread, how do one identify the pointer
>> to an opaque type as a sampler?  As Tanya noted earlier, one can't rely
>> on the name as it can be renamed.  As an aside, if a sampler is unused,
>> is there any reason why one would need to preserve the info?
> [Villmow, Micah] Yes, a kernel argument must have information about what the arguments are, even unused ones.
> 

I was thinking about program level samplers. Yes, function parameters will need to preserve its info like they naturally do.  The main question remains on how to identify it without using the type name (.e.g., one could use metadata).

  -- Mon Ping


> 
>> 
>>> I feel the need for optimizations is barely there for samplers and so
>>> we need to consider the representation issue first.
>>> 
>> 
>> I agree that the representation here is what is important.  I'm not
>> concerned with the optimizations other than they should just work with
>> SPIR without affecting any semantics.
>> 
>>   -- Mon Ping
>> 
>>> 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
>>> 
>>> _______________________________________________
>>> 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