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

Tue Oct 9 13:08:30 PDT 2012

Tanya,
I tend to agree with Micah:
Using i32 to represent samplers seems reasonable for most purposes, but in OpenCL sampler is not the same as int/uint. The only thing that really makes sampler_t look like uint is its initialization, but that's it: one cannot do any arithmetic operations on samplers, can't get the initializer value of samplers or pass samplers as integers and vice-versa.

Also, one can imagine implementations that would hold some optimization related info in the samplers: supposedly one could statically initialize a set of function pointers or other optimization data based on the initialize value - this initialization could be decided in compilation time. I guess this was the intention of the OpenCL spec, otherwise I'm not sure why are all the sampler specific restriction there - if the sampler was supposed to be a simple integer value, then one should be able to query its value, and do some bitwise operations to change the sampler behavior in runtime.

Please check the latest version I've sent - deriving from the CGOpenCLRuntime class there one could easily use i32 instead of these opaque type pointers for samplers.

Thanks
[email_signature_guy_new2]

From: Villmow, Micah [mailto:Micah.Villmow at amd.com]
Sent: Tuesday, October 09, 2012 20:44
To: Tanya Lattner
Cc: Benyei, Guy; cfe-dev at cs.uiuc.edu; Anton.Lokhmotov at arm.com
Subject: RE: [cfe-dev] OpenCL & SPIR specific types - proposal and patch

From: Tanya Lattner [mailto:lattner at apple.com]
Sent: Tuesday, October 09, 2012 11:30 AM
To: Villmow, Micah
Cc: Benyei, Guy; cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>; Anton.Lokhmotov at arm.com<mailto:Anton.Lokhmotov at arm.com>
Subject: Re: [cfe-dev] OpenCL & SPIR specific types - proposal and patch

On Oct 4, 2012, at 1:14 PM, "Villmow, Micah" <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote:

There needs to be a way to differentiate between an integer and a sampler by only looking at the type. The sampler itself is an opaque type in OpenCL. The only requirement is that it is initialized with a 32bit unsigned integer, not that the type itself is an integer.

I understand that the spec doesn't require it to be a 32 bit integer, but if you are only ever assigning it a 32 bit integer, it doesn't make any sense to have the extra inttoptr instruction.

Secondly, your idea of differentiating an integer and sampler by type alone is then based upon the name of the type that you are pointing to and not actually the type itself. Anything based upon names can be risky. There was a point in time where the linker was not properly merging structures that were identical and therefore renaming them. It makes much more sense to attach metadata to samplers and images to denote what is what.
[Villmow, Micah] Metadata isn't possible because you can't attach metadata to arguments.
Take these functions:
Kernel void foo(sampler_t a, int b)
{
}
Kernel void foo(int a, int b)
{
}
In LLVMIR with sampler as i32, they are both the same function, but they are fundamentally different and have to be handled differently(not only at the compiler level, but also at the runtime level). On a 32bit system, on the runtime side, the size of a sampler_t object is 4 bytes, on a 64bit system it is 8 bytes, but as an i32, its always 4 bytes.

Another problem is this case:
Module 1:
int foo(sampler_t a, int b)
{
Return 0;
}
Module 2:
int foo(int a, int b)
{
Return 0;
}
Module 3:
Kernel void bar(global int* a, sampler_t b)
{
*a = foo(b, *a);
}

Linking Module 1 and 3 together is fine, linking module 2 and 3 together should produce a linker error. If a sampler is an i32, they both are accepted since they have the same signature.

I agree that the opaque pointer with a specific name isn't the best solution, but unless we add these as fundamental LLVM types, I don't know of a better way to handle this. I however think relying on metadata for information that is required for correctness is wrong(metadata should not affect correctness) and differentiating if an i32 is a sampler or not based on its use is not the right approach either.

The image types being pointers I am fine with as there isn't any other way to do those.

-Tanya

Micah

From: Tanya Lattner [mailto:lattner at apple.com<http://apple.com>]
Sent: Thursday, October 04, 2012 11:49 AM
To: Benyei, Guy
Cc: cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>; Villmow, Micah; Anton.Lokhmotov at arm.com<mailto:Anton.Lokhmotov at arm.com>
Subject: Re: [cfe-dev] OpenCL & SPIR specific types - proposal and patch

I'm hoping to have comments on this patch tomorrow, but since I have proposed several patches to Clang for the sampler type (and have another in revision).. can you explain why you want to change the type from an integer to a pointer?

-Tanya

On Oct 3, 2012, at 8:06 AM, "Benyei, Guy" <guy.benyei at intel.com<mailto:guy.benyei at intel.com>> wrote:

I'd like to renew the discussion about making the OpenCL specific types first class citizens in Clang.

I think this change is required by the OpenCL specifications, since these type names are keywords of the OpenCL C language.
This change is also needed in order to enable efficient checking of OpenCL restrictions on these types (OpenCL 1.2 spec, section 6.9).
Furthermore, the proposed change will turn these types to pointers to opaque types, which means that it will hide the actual (vendor specific) implementation, so the OpenCL vendors using Clang will be able to implement these types in their own way.

This change would also be a basis for the implementation of SPIR generation by Clang. The SPIR discussion and spec can be found here:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-September/024132.html
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-September/024178.html

Earlier discussion about the OpenCL types was started by Anton Lokhmotov:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-May/015297.html
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014741.html
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-March/014118.html
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-March/014121.html

<image001.png>

<opencl_types.patch>

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121009/127c01e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 24800 bytes
Desc: image001.png
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121009/127c01e4/attachment.png>