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

Wed Sep 12 12:30:08 PDT 2012


> -----Original Message-----
> From: mankeyrabbit at gmail.com [mailto:mankeyrabbit at gmail.com] On Behalf
> Of James Molloy
> Sent: Wednesday, September 12, 2012 12:18 PM
> 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, David,
> 
> Thanks for taking my responses on board.
> 
> > 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?
> 
> Hmm, this is the one I was most shaky on. I still don't fully
> understand what you're using this calling convention for, other than:
> 
>   1. A marker to distinguish kernels from regular functions, in which
> case there are better ways to do that (metadata)
[Villmow, Micah] I disagree, the 'kernel' keyword specifies a different calling convention from functions that don't have it. So we need a calling convention that maps to that. The ABI for a kernel is different than the ABI for a non-kernel function. The regular function itself also is different than the default calling convention because it has restrictions on it(one being it can only be called from a kernel function or another device function) that the normal calling convention does not. A way to think about this is that this is more similar to the PTX_[Kernel|Device] calling conventions than the default, fast or stdcall conventions. I don't think metadata is the right approach here since we are specifying unique ways for how these functions can be called.
 
>   2. A way to remove remnants of the platform or C calling convention.
> In this case, I've mentioned that there are things such as
> pass-struct-by-pointer that are lowered in the IR-generation stage
> that you haven't addressed. Without addressing this (the
> IR-generator's part of the ABI compliance contract), I'm not sure how
> a new LLVM calling convention helps remove platform dependence.
[Villmow, Micah] Ok, fair point, this is something that the specification should probably address.
> 
> Although I may have missed a/the point somewhere along the line, I've
> been a bit ill in recent days and not fully engaged, brain-wise :)
> 
> Cheers,
> 
> James
> 
> On 12 September 2012 19:54, Ouriel, Boaz <boaz.ouriel at intel.com> wrote:
> > 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.
> >