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

[David Neto]

If a sampler_t is just an i32 constant, then why didn't OpenCL C just
define a sampler_t to be a 32-bit constant?  There must have been a
reason.

I looked at the OpenCL spec and apparently some devices limit the
number of samplers that can be used in a kernel.  See
CL_DEVICE_MAX_SAMPLERS in Table 4.3 (OpenCL device queries).

This probably implies that it's important on some architectures for
either functionality or performance reasons to preserve the sampler
*variables*.   In other words, *avoid* constant folding and
propagation so that some samplers would potentially disappear.

If I understand things correctly, in SPIR the preservation of the
sampler *variables* is a side effect of the calls to
@__spir_sampler_initialize in @__spir_globals_initializer().


david


On Fri, Oct 12, 2012 at 6:28 PM, Mon P Wang <monping at apple.com> wrote:
> Hi,
>
> On Oct 12, 2012, at 7:56 AM, Anton Lokhmotov wrote:
>
> I agree with Micah and Guy that the sampler type should be an opaque type.
> The i32 solution has too many cons, and the pros are not clear-cut either.
> (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?
>
>
>
> The problem with renaming of opaque types should better be solved by
> extending LLVM to disallow renaming given types.
>
> Without seeing a follow-up patch, I cannot comment on the use of functions
> to initialize samplers.  In our implementation, we use both opaque types and
> metadata, which works fine.
>
> Anton.
>
>
> From: Villmow, Micah [mailto:Micah.Villmow at amd.com]
>
> Sent: 12 October 2012 00:02
> To: Tanya Lattner
> Cc: Benyei, Guy; cfe-dev at cs.uiuc.edu; Anton Lokhmotov
> Subject: RE: [cfe-dev] OpenCL & SPIR specific types - proposal and patch
>
> If the type gets renamed, how are you going to identify what is a sampler?
> [Villmow, Micah] Usage.
>
> See my comment above about linking and opaque types as it doesn't solve that
> problem for you either.
>
> Can you please share your list of pros and cons of pointer to opaque type
> versus int?
> [Villmow, Micah] Sure, here is what I view as the pros and cons.
> Opaque type:
> Pros:
> Implementation details are target dependent
> No confusion with valid i32 type
> Utilizes the type system instead of metadata
> Can be materialized to i32 if needed
>
>
> Sorry, I don't quite understand.  If it can be materialized as a i32 type,
> wouldn't this transformation lead it to be confused as a valid i32 type?
>
>
> No operations can occur on the type.
> Easier to track through stack.
> Cons:
> Can be renamed and loose information
> Requires initialization function
>
>
> Requiring initialization functions to be generated for CL where CLK_* are
> integer enums is a bit strange for a C based language.
>   const sampler_t samplerA = CLK_NORMALIZED_COORDS_TRUE | CLK_ADDRESS_REPEAT
> |
> CLK_FILTER_NEAREST;
>
>
> Requires global variables
>
>
> I'm not sure what that means.  For program scope samplers, wouldn't we use
> global variables?
>
>
> I32:
> Pros:
> Can be initialized inline and constant propagated.
> Already works(for AMD at least).
> Metadata can make for easy identification if it exists.
> Maps 1-1 to initializers
>
> Cons:
> Optimizers don’t know the differences between sampler and other i32
>
>
> We know at the CL language level that this is a const value or a constant.
> I don't see why we would do any optimizations on this variable other than
> constant propagating to its use as a bad thing  (in the case of program
> scope sampler).
>
> Harder to track through stack
>
>
> I'm not sure what you mean here of harder to track through the stack.  Since
> this a const value, I would expect it to be used directly by its use (e.g.,
> read_image).
>
> An integer i32 and a sampler_t i32 is only determined by usage and not type.
>
>
> If you use metadata, this is not an issue.  Are we trying to make LLVM IR
> here into a high level IR with type safety?
>
> Operations can work on the type, which is illegal.
>
>
> What operations will be done on this type?  It is true that this could
> happen but since at the CL level, the value is const so I don't expect any
> optimization to manipulate it other than to constant propagate the value to
> its use.
>
> Metadata can be lost requiring extensive analysis which cannot always be
> determined.
>
>
>
> Metadata doesn't get dropped on globals or functions.
>
>
> -- Mon Ping
>
>
> -Tanya
>
> _______________________________________________
> 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
>