From: firstname.lastname@example.org [mailto:email@example.com] On Behalf
Of James Molloy
Sent: Tuesday, September 11, 2012 1:45 PM
To: Villmow, Micah
Cc: James Molloy; Ouriel, Boaz; firstname.lastname@example.org; email@example.com
Subject: Re: [cfe-dev] [LLVMdev] SPIR provisional specifciation is now
available in the Khronos website
>> (a) You mention special calling conventions and adding them to LLVM.
>> What are their semantics? And what is their purpose?
> [Villmow, Micah] One purpose is to differentiate between kernel and
> Another is to differentiate between the standard calling conventions
> that have device specific assumptions built into them.
Do you have an example of such a device-specific assumption? Why
wouldn't the default (no explicit) calling convention do for a storage-
only format like SPIR?
[Villmow, Micah] It is my understanding, and correct me if I'm wrong, clang
generates code based on the calling convention and the device. We don't want
any assumptions made about the device calling convention until SPIR loading time and
the cleanest way to do that is to introduce our own. Also the default calling convention in LLVM is C, which
does not have the same semantics as ours(for example varargs is illegal except for printf, kernels and functions are different, etc...).
When it does come to codegen (for a CPU target), an LLVM backend would
be forced to change the calling convention back to something standard
anyway. So what's the advantage of adding a semanticless calling
convention over metadata?
[Villmow, Micah] I wouldn't say it is semantic-less, just that its semantics are different than the calling conventions that LLVM currently supports.
>> (b) Why disallow type conversion for vector types? (ss. 3.3)
> [Villmow, Micah] Type conversions in OpenCL between vector types is
> doing via builtin functions and not via implicit conversions, so there
> is no OpenCL code that can generate these conversions directly(OpenCL
> spec 6.2.1). In order to be portable, library functions cannot be
> lowered to their IR equivalent until after the device is known.
Is SPIR meant to be storage-only, or to allow optimisations to be done
on it (valid SPIR -> opt -> valid SPIR)?
[Villmow, Micah] While you can optimize SPIR, you run the chance of reducing portability by optimizing in a non-portable manner. The SPIR spec does not specify how the SPIR is generated or what is done to the binary format before generation, only what is and isn't valid. It is quite possible to generate valid SPIR that is non-portable, but in this case, there is no reason for using SPIR.
If you allow scalar type conversions, and you allow vectors, it follows
that an optimiser may turn scalar type conversions into vector type
conversions. Why explicitly disallow this even though there is no
corollary directly from CL-C source code?
[Villmow, Micah] SPIR in its current form is limited to OpenCL C(being an OpenCL extension). So things that are disallowed in OpenCL C are disallowed in SPIR at this time.