[LLVMdev] SPIR provisional specifciation is now available in the Khronos website

[Hal Finkel]

Boaz,

The current specification provides a mechanism for handling
FP_CONTRACT, but does so only at the module level. After much debate,
we have adopted and implemented a way of handling FP_CONTRACT in
clang/LLVM through the llvm.fmuladd intrinsic (currently in trunk). I
suggest that the proposed spir.disable.FP CONTRACT metadata be replaced
with the current llvm.fmuladd-based mechanism.

 -Hal

On Tue, 11 Sep 2012 11:56:42 +0000
"Ouriel, Boaz" <boaz.ouriel at intel.com> wrote:

> Hi All,
> 
> In continuation of the previous SPIR introduction email here is a
> link to the specification:
> http://www.khronos.org/registry/cl/specs/spir_spec-1.0-provisional.pdf
> 
> The first topic which we would like to discuss is "SPIR portability".
> I will send soon an additional mail which will help in leading the
> discussion on this topic.
> 
> Thanks and happy reading,
> Boaz
> 
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu
> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Ouriel, Boaz Sent:
> Thursday, September 06, 2012 22:06 To: cfe-dev at cs.uiuc.edu;
> llvmdev at cs.uiuc.edu Subject: [LLVMdev] "SPIR" - A Standard Portable
> IR for OpenCL Kernel Language
> 
> 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.
> 
> 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
> ---------------------------------------------------------------------
> 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



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory