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

[Villmow, Micah]

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/20121011/168a1edb/attachment.html>