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

[Anton Lokhmotov]

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

 

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

No operations can occur on the type.

Easier to track through stack.

Cons:

Can be renamed and loose information

Requires initialization function

Requires 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

Harder to track through stack

An integer i32 and a sampler_t i32 is only determined by usage and not type.

Operations can work on the type, which is illegal.

Metadata can be lost requiring extensive analysis which cannot always be
determined.

 

 

-Tanya

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