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

[Villmow, Micah]

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