[LLVMdev] "SPIR" – A Standard Portable IR for OpenCL Kernel Language

Fri Sep 7 10:47:22 PDT 2012

On 09/06/2012 03:05 PM, Ouriel, Boaz wrote:
> Greetings All,
> I am sending this mail on behalf of the OpenCL Khronos members.
>
> **** Introduction ****
> Lately, Khronos has ratified a new provisional specification which is called SPIR.
> This specification standardizes an intermediate representation for the OpenCL kernel language.
> It is based on LLVM infrastructure and this is why I am sending this mail to the LLVM mailing list.
> Khronos members would like to initiate a review on the specification with the LLVM community.
>
> **** What is SPIR? ****
> The SPIR specification standardizes an intermediate representation for OpenCL programs,
> which a hypothetical frontend can target to generate binaries that can be consumed and executed by OpenCL drivers supporting SPIR.
> The SPIR specification, however, does not standardize the design and implementation of such a frontend.
>
> **** SPIR and LLVM ****
> Khronos members chose SPIR to be layered on top of LLVM.
> Why?  Portability is a key goal of SPIR, and LLVM has proven to be highly portable, given its many backends.
> Defining a robust IR for OpenCL from scratch is difficult and requires skills which are not the core competency of the OpenCL Khronos members.
> In addition, after the IR is defined, implementing the necessary SW stack around it is a huge investment.  LLVM thus provides a time-to-market advantage for SPIR.
> Today, many of the OpenCL vendors base their technology on LLVM. This makes LLVM IR the de facto OpenCL IR and the immediate candidate to be considered by the Khronos members.
> An analysis showed that LLVM IR has its limitations but in general provides a very good solution for SPIR.
>
> **** Minimal Changes to LLVM ****
> When defining SPIR, Khronos set a goal to keep the changes in LLVM minimal.
> Most of the changes made during prototyping were in the frontends that the different OpenCL Khronos members used.
> The only changes required by SPIR in LLVM are a new target for SPIR, a new calling convention for regular OpenCL functions, and another one for OpenCL kernels.
> LLVM IR language definition remains unmodified.
>
> **** Why is SPIR important for OpenCL? ****
> SPIR offers binary portability between OpenCL implementations, and a stable target for 3rd party compilers without having to go through OpenCL "C".
>
> Binary compatibility simplifies the support burden for developers delivering applications that use OpenCL.
> The same application can be delivered in fully binary form and work across existing and future OpenCL implementations supporting SPIR.
> This helps the entire OpenCL ecosystem.
>
> Generally speaking OpenCL is a JIT environment and as such deserves and requires an intermediate representation like other major JIT environments already have.
>
> Also, some developers using OpenCL have requested portability at binary level.  Today OpenCL offers portability only at the source level with OpenCL “C”.
> They are concerned with protecting their IP by meeting “Digital Millennium Copyright Act” requirements.
> Today, those companies are forced to distribute their OpenCL code using device specific binaries. This leads to many difficulties for SW developers and end users.
>   In addition, the binaries are not guaranteed to be functionally working as new devices and vendors appear in the market.
> This constraint places OpenCL standard in a disadvantage compared to other standards which already have a portable binary distribution form.
>  From discussions with some of the companies which raised the request, LLVM IR meets their requirements.
> SPIR doesn’t guarantee any security / obfuscation mechanisms. It just provides a portable IR definition.
>
> Khronos members also believe that SPIR will enable data parallel domain specific languages which will generate directly to SPIR and execute on top of OpenCL runtimes.
>
> **** SPIR Portability vs. OpenCL “C” ****
> Portability is one of SPIR’s goals. However, SPIR does not attempt to solve inherent portability issues, which exist in OpenCL “C” or in C99.
> It is clear that OpenCL programs could be written in a way which make them non portable and very device specific.
> Such programs will never be portable. In addition, some corner case scenarios which have been identified by Khronos have been disallowed in SPIR.
> SPIR does not guarantee performance portability across devices. This is also true for OpenCL “C”.
>
> **** Is this the final version of SPIR specification (set in stone?) ****
> The short answer is “NO”, it is not final.
>
> All along the definition stage of SPIR, Khronos had the goal of reviewing this proposal and collecting feedback on its content with LLVM community.
> This feedback is not a “nice to have” but rather “a must have”.
> So why didn’t we define the specification with the community right from the start? The answer to that has two aspects.
> The first is that Khronos members wanted to do their homework and make sure that the proposal is mature enough to start discussions based on it.
> The due diligence includes full implementation of the specification by a few members within Khronos.
> The second aspect is the legal part which prevented Khronos from sharing this information publicly until the specification is ratified inside Khronos.
> The current version of SPIR specification which is shared with LLVM community is a provisional specification.
> The main goal of this version of the specification is to collect feedback from LLVM community, apply the changes and shape the specification to its final version.
>
> **** Suggested review process ****
> SPIR introduces an intermediate language for OpenCL and hence is a very large specification with many details and a lot of topics to discuss.
> Khronos will share the specification with the LLVM community as a reference.
> However, Khronos believes that the right approach is to review it in parts:  by peeling the different layers and aspects of the specification, layer by layer (the “onion” way),
> going from top to bottom and topic by topic.
>
> Each such topic would be contained in an email thread in LLVM mailing list. Since SPIR specification deals with the “HOW”, and not with the “WHY”,
> each topic will be associated with a short document that aims at providing insights into the considerations and goals behind the way it was defined in SPIR specification.
> Some of the discussions would be accompanied by pieces of code in CLANG or LLVM that demonstrate what has been implemented by Khronos members.
> A successful discussion would result with a decision acceptable by both LLVM community and Khronos.
> We expect that many discussions will move to LLVM Bugzilla for resolution.  This should improve convergence.
>
> We do not want to fork LLVM.  We plan to evolve SPIR in response to LLVM community feedback.
> In addition, where applicable - Khronos members would like to upstream the relevant changes to LLVM and not wait for the entire review of the specification to be completed.
> Khronos members do realize that applying changes to the LLVM code will not always be possible since some discussions depend on other discussions.
>
> Why not review the entire specification as a whole? Doing the review on the entire specification would make the discussions unfocused and difficult to track.
> We expect discussions will be more effective and converge better by a piecemeal approach.
> That being said, we will try to keep the proposal coherent at a high level.
>
> **** clang as a sample OpenCL SPIR generator ****
> Even though SPIR does not standardize the generation process, the Khronos working group would like clang to eventually become the sample OpenCL SPIR generator.
> So why only make it a sample generator? Khronos wanted to permit the different OpenCL vendors to choose their own frontend technology and not require them to use CLANG.
>
> Also, we avoid using clang as a reference generator because any discrepancy between SPIR outputs generated by clang and the SPIR spec will be resolved in favor of the spec.
> That is, implementers of other SPIR generators would not be required to maintain bug compatibility with clang.
>
> **** Suggested Topics to discuss ****
>
> This is the list of suggested topics to discuss:
> 1.    SPIR specification introduction and scope (this mail)
> 2.    SPIR Portability
>       a.    32 / 64bits architectures (pointers, size_t, ptrdiff_t, intptr_t, uintptr_t)
>       b.    Endianness in OpenCL “C”
> 3.    OpenCL built-ins in SPIR
>       a.    OpenCL Built-ins & LLVM Built-ins
>       b.    Name Mangling
> 4.    OpenCL Metadata Arrangement
> 5.    OpenCL Specific items
>      a.    OpenCL special data types (events, images, samplers) as opaque data types
>      b.    Null and zeroinitializer
>      c.    Local Memory and alloca’s
>      d.    Others
>
> **** Where can I find SPIR specification? ****
> Khronos is now working on making SPIR specification available through the Khronos website.
> Once available, we will send a link to the document in this mailing list.

Any timeframe for the release?

>
> I am sure this is going to be a lot of fun :),
> Boaz
> ---------------------------------------------------------------------
> 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.
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- 
Thanks,

Justin Holewinski