[LLVMdev] [cfe-dev] SPIR provisional specification is now available in the Khronos website

Ouriel, Boaz boaz.ouriel at intel.com
Wed Sep 12 11:54:00 PDT 2012 

Hi James,

This is very good feedback. 

1. Adding the new calling conventions - It seems like the appropriate thing to do vs. metadata. Some OpenCL backends can choose to implement this calling convention and use it during code generation of OpenCL functions/kernels.  Can we agree on this item?
2.  Restricting the allowable instructions - As Micah mentioned before, the restrictions are there because we are only looking at this for OpenCL at this time. Hence, we currently only map what OpenCL supports.  However, I agree that this might make some optimizations incompatible with SPIR. Let me discuss this a bit further in Khronos and come back with additional feedback. 

Thanks,
Boaz

-----Original Message-----
From: mankeyrabbit at gmail.com [mailto:mankeyrabbit at gmail.com] On Behalf Of James Molloy
Sent: Wednesday, September 12, 2012 11:08
To: Ouriel, Boaz
Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu; Villmow, Micah
Subject: Re: [cfe-dev] [LLVMdev] SPIR provisional specification is now available in the Khronos website

Hi Boaz, Micah,

Thanks for the followup.

> I agree with Micah that optimizing a SPIR module might make it less portable.
> However, SPIR doesn't prohibit optimizations. It is up to the OpenCL optimizer to decide when to "materialize" SPIR to a device specific LLVM module or even convert it to another IR.
> It would be useful if we could identify areas in the specification that might break this assumption and discuss the observed limitations.
> I think SPIR's offering would be stronger if optimizations could be performed safely.
> So the answer to your question is: no, it is not just a storage-only format.

My only issue then, is if it is not specifically designed to be a
storage-only format, why restrict the allowable instructions to the
strict set that can be generated by an OpenCL-C frontend? This would
make sense for a storage-only format, but as soon as you let
optimizers loose on it it will by definition change the IR. The
transformation from scalar extractelement/fptoint/insertelement to a
vector fptoint is one concrete example I noticed when perusing the
spec where a valid, and target independent, optimisation could result
in invalid SPIR. I was wondering the benefit of restricting the
allowable instructions so strongly.

> Q: So what's the advantage of adding a semantic-less calling convention over metadata?
>
> Metadata could be used as well, and in fact - this is the current approach used by clang today.
> 1. However, since this is not a storage-only format, we felt that it would be useful to differentiate the calling conventions from the existing ones in LLVM.
> 2. Also, since SPIR kernels & functions are device and OS agnostic no calling convention is really suitable for SPIR. Hence, we chose to introduce new ones.
> 3. Another smaller reason in favor of a new calling convention vs. metadata is the fact that metadata can't be associated to functions in LLVM.  This makes the metadata arrangement a bit more complex and less trivial to access by OpenCL optimizers.

My worry here, (and please take this with a pinch of salt because I am
by no means one of the core LLVM developers), is that calling
conventions in the IR are primarily related to code generation. As
SPIR isn't going to be used for codegen (pass SPIR to some backend /
converter that is responsible for that), why worry about the calling
convention? All it is is a wart, it doesn't affect midend phases at
all.

I should note that passing structs (byval or not) in the first
parameter as an sret argument is *independent of the LLVM calling
convention*, and is done at the Clang level. This is part of
LLVM/Clang where responsibility for adhering to an ABI overlaps
between the IR-generator and the IR itself. Adding a new calling
convention in IR and marking functions with it won't stop the IR
generator having to make ABI decisions.

Not only that, but for valid codegen any backend is going to have to
remove those calling convention markers anyway and replace them with
their own, so why have them in the first place?

I've rambled slightly, sorry about that!

On 12 September 2012 00:00, Ouriel, Boaz <boaz.ouriel at intel.com> wrote:
> Hi James,
>
> some additional comments regarding some of your questions:
> Q: Is SPIR meant to be storage-only, or to allow optimizations to be done?
>
> I agree with Micah that optimizing a SPIR module might make it less portable.
> However, SPIR doesn't prohibit optimizations. It is up to the OpenCL optimizer to decide when to "materialize" SPIR to a device specific LLVM module or even convert it to another IR.
> It would be useful if we could identify areas in the specification that might break this assumption and discuss the observed limitations.
> I think SPIR's offering would be stronger if optimizations could be performed safely.
> So the answer to your question is: no, it is not just a storage-only format.
>
>
> Q: So what's the advantage of adding a semantic-less calling convention over metadata?
>
> Metadata could be used as well, and in fact - this is the current approach used by clang today.
> 1. However, since this is not a storage-only format, we felt that it would be useful to differentiate the calling conventions from the existing ones in LLVM.
> 2. Also, since SPIR kernels & functions are device and OS agnostic no calling convention is really suitable for SPIR. Hence, we chose to introduce new ones.
> 3. Another smaller reason in favor of a new calling convention vs. metadata is the fact that metadata can't be associated to functions in LLVM.  This makes the metadata arrangement a bit more complex and less trivial to access by OpenCL optimizers.
>
> Does this make sense? Do you see an issue with adding the suggested calling conventions?
>
> Thanks,
> Boaz
>
> -----Original Message-----
> From: Villmow, Micah [mailto:Micah.Villmow at amd.com]
> Sent: Wednesday, September 12, 2012 00:03
> To: James Molloy
> Cc: James Molloy; Ouriel, Boaz; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
> Subject: RE: [cfe-dev] [LLVMdev] SPIR provisional specifciation is now available in the Khronos website
>
>
>
>> -----Original Message-----
>> From: mankeyrabbit at gmail.com [mailto:mankeyrabbit at gmail.com] On Behalf
>> Of James Molloy
>> Sent: Tuesday, September 11, 2012 1:45 PM
>> To: Villmow, Micah
>> Cc: James Molloy; Ouriel, Boaz; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
>> Subject: Re: [cfe-dev] [LLVMdev] SPIR provisional specifciation is now
>> available in the Khronos website
>>
>> Hi Micah,
>>
>> >> (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.
>>
>> 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.
>>
>> Cheers,
>>
>> James
>>
>> On 11 September 2012 16:54, Villmow, Micah <Micah.Villmow at amd.com>
>> wrote:
>> >
>> >
>> >> -----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
>> >
>> >
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > 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.
>
---------------------------------------------------------------------
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.

More information about the llvm-dev mailing list