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

[Mon P Wang]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121012/ae8357b2/attachment.html>