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

[Villmow, Micah]

> -----Original Message-----
> From: Mon Ping Wang [mailto:monping at apple.com]
> Sent: Thursday, October 18, 2012 11:00 AM
> To: Villmow, Micah
> Cc: Sumesh Udayakumaran; cfe-dev at cs.uiuc.edu; Anton.Lokhmotov at arm.com
> Subject: Re: [cfe-dev] OpenCL & SPIR specific types - proposal and
> patch
> 
> 
> 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).
[Villmow, Micah] The problem with the metadata approach is that it can only be attached to instructions, of which arguments are not, and the design of metadata is that the program should be executed correctly if it is dropped. 
> 
>   -- Mon Ping
> 
>