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

[Mon Ping Wang]

Hi,

On Oct 12, 2012, at 4:48 PM, David Neto <dneto.llvm at gmail.com> wrote:

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

Sure, there are good reasons.  I think it makes it clearer to define it as a type just like people find it clearer to typedef enums. 

> 
> 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().
> 

Sure, hardware have a limit on the number of samplers in a kernel but do they really want to preserve the number of sampler variables or the number of unique samplers values?  Is the preservation of the variable desirables when two samplers are identical and one is losing one of these valuable resources?

  -- Mon Ping


> 
> 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
>> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev