llvm dev - Sep 2012 - [LLVMdev] SPIR provisional specifciation is now available in the Khronos website

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.

Hi Boaz,

I have a couple of specific questions:

(a) You mention special calling conventions and adding them to LLVM.
What are their semantics? And what is their purpose?

(b) Why disallow type conversion for vector types? (ss. 3.3)

Cheers,

James

On Tue, 2012-09-11 at 12:56 +0100, Ouriel, Boaz 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
>

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of James Molloy
> Sent: Tuesday, September 11, 2012 8:49 AM
> To: Ouriel, Boaz
> Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] SPIR provisional specifciation is now available
> in the Khronos website
> 
> Hi Boaz,
> 
> I have a couple of specific questions:
> 
> (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 device
functions.
Another is to differentiate between the standard calling conventions that have
device specific assumptions built into them.
> 
> (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.
> 
> Cheers,
> 
> James
> 
> On Tue, 2012-09-11 at 12:56 +0100, Ouriel, Boaz 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
> >
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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

James, here are our updated answers after discussing
this.
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of James Molloy
> Sent: Tuesday, September 11, 2012 8:49 AM
> To: Ouriel, Boaz
> Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] SPIR provisional specifciation is now available
> in the Khronos website
> 
> Hi Boaz,
> 
> I have a couple of specific questions:
> 
> (a) You mention special calling conventions and adding them to LLVM.
> What are their semantics? And what is their purpose?
[Villmow, Micah] The semantics of the new calling conventions are as follows:
spirfunc calling convention -
All arguments are passed as is to the function with the exception of structures,
no lowering or expansion is allowed.
Structures are passed as a pointer to struct with the byval attribute set.
Functions marked with spirfunc calling convention can only be called by another
function marked with either spirfunc or spirkrnl calling conventions.
Functions marked with spirfunc calling convention can only call functions marked
with spirfunc or spirkrnl calling conventions.
Functions marked with spirfunc calling convention can only have zero or 1 return
values.
Functions marked with spirfunc calling convention are only visible to the
device.
Variable arguments are not allowed, except for printf.
This calling convention does not specify the how it is lowered to registers or
how the return value is specified.

spirkrnl calling convention -
Inherits the definition of spirfunc calling convention.
Functions marked with spirkrnl calling convention cannot have any return values.
Functions marked with spirkrnl calling convention cannot have variable
arguments.
Functions marked with spirkrnl calling convention can be called by the host.
Functions marked with spirkrnl calling convention are externally
visible.
> 
> (b) Why disallow type conversion for vector types? (ss. 3.3)
[Villmow, Micah] There are a few reasons.
1) SPIR wants to map as close to OpenCL as possible and while the vector type
conversions are well defined in LLVM and properly converts to scalar when
needed, SPIR needs to be able to work with people who don't use LLVM. By
adhering as close as possible to OpenCL C, the amount of work to support SPIR is
reduced.
2) From what I've been iformed of by Aaftab Munshi, when OpenCL C was
developed, there were many different implementations that supported vector
casts, but they were not conversion casts(e.g. Altivec/Cell C extensions). So
OpenCL requires explicit vector conversion functions, and as such SPIR inherits
those rules.
3) Since many compilers already had the vector casts that weren't
conversions, the function calls were required so that code could not be written
expecting the prior behavior of other compilers in OpenCL.


Hope that helps answer the questions,
Micah
> 
> Cheers,
> 
> James
> 
> On Tue, 2012-09-11 at 12:56 +0100, Ouriel, Boaz 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
> >
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev