similar to: [LLVMdev] SPIR Review Status: after Introduction and 32bits vs. 64bits discussions

Displaying 20 results from an estimated 6000 matches similar to: "[LLVMdev] SPIR Review Status: after Introduction and 32bits vs. 64bits discussions"

2012 Sep 19
0
[LLVMdev] [cfe-dev] SPIR Review Status: after Introduction and 32bits vs. 64bits discussions
Ouriel, Boaz wrote: ... *** Richard Smith, Eli Friedman & Nadav Rotem: Portability Issues *** *****comment 1: int does_this_compile[sizeof(void*) - 3]; Answer: We are discussing this internally and will provide an answer soon. ****comment 2: struct how_do_you_represent_this_in_IR {
2012 Sep 19
1
[LLVMdev] [cfe-dev] SPIR Review Status: after Introduction and 32bits vs. 64bits discussions
On Wed, Sep 19, 2012 at 5:43 AM, Benyei, Guy <guy.benyei at intel.com> wrote: > Ouriel, Boaz wrote: > > > ... > > > *** Richard Smith, Eli Friedman & Nadav Rotem: Portability Issues *** > > *****comment 1: int does_this_compile[sizeof(void*) - 3]; > Answer: We are discussing this internally and will provide an answer soon. >
2012 Sep 12
5
[LLVMdev] SPIR Portability Discussion
Hey All, This is a very big topic in SPIR and probably a very controversial one as well. It includes dealing with 32 vs. 64 bit architectures and OpenCL "C" endianness. We have written down some of the aspects, but of course did not cover everything - let's start a discussion on the portability and see where it takes us. I suggest we start with the 32 vs. 64 bits discussion and then
2012 Sep 12
0
[LLVMdev] SPIR Portability Discussion
On Wed, Sep 12, 2012 at 12:27 PM, Ouriel, Boaz <boaz.ouriel at intel.com>wrote: > Hey All, > > This is a very big topic in SPIR and probably a very controversial one as > well. It includes dealing with 32 vs. 64 bit architectures and OpenCL "C" > endianness. > We have written down some of the aspects, but of course did not cover > everything - let's start
2012 Sep 27
0
[LLVMdev] SPIR: Answers to the issues raised so far
Hi All, Here are answers to the questions / comments that were raised so far during the SPIR discussions. **** A general clarification regarding sizeof **** In SPIR, sizeof in an integer constant expression is illegal. The reason behind it is that once the device is no longer known, the width of the unsigned integer that represents the size_t type is no longer known. The C spec states in
2012 Sep 12
2
[LLVMdev] SPIR Portability Discussion
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Richard Smith Sent: Wednesday, September 12, 2012 1:55 PM To: Ouriel, Boaz Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] SPIR Portability Discussion On Wed, Sep 12, 2012 at 12:27 PM, Ouriel, Boaz <boaz.ouriel at intel.com<mailto:boaz.ouriel at intel.com>> wrote: Hey
2012 Sep 12
0
[LLVMdev] SPIR Portability Discussion
> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Nadav Rotem > Sent: Wednesday, September 12, 2012 2:17 PM > To: Richard Smith > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] SPIR Portability Discussion > > > > > OpenCL 1.2 (6.3)/k says the result of sizeof
2012 Sep 12
0
[LLVMdev] SPIR Portability Discussion
> > ****Pointers**** > During SPIR generation, the size, and the alignment of pointers is unknown (32 vs. 64 bits). > The SPIR representation shouldn't assume anything about the size and the alignment of pointers, > but it might use pointers in the usual way (except from using GEP when the pointed type has unknown size - this one is illegal in SPIR and will fail the
2012 Sep 12
2
[LLVMdev] SPIR Portability Discussion
> > OpenCL 1.2 (6.3)/k says the result of sizeof is an ICE. So these are valid: > > int does_this_compile[sizeof(void*) - 3]; > > struct how_do_you_represent_this_in_IR { > int a : 1; > int b : sizeof(void*) * 4; > }; > > Is OpenCL going to be changed to reject these cases? > I don't think that they plan to allow it. I am not sure how much value
2012 Sep 12
3
[LLVMdev] SPIR Portability Discussion
From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of Richard Smith Sent: Wednesday, September 12, 2012 2:51 PM To: Villmow, Micah Cc: Ouriel, Boaz; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] SPIR Portability Discussion On Wed, Sep 12, 2012 at 2:23 PM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote: From:
2012 Sep 12
0
[LLVMdev] SPIR Portability Discussion
On Wed, Sep 12, 2012 at 2:23 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > ** ** > > ** ** > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Richard Smith > *Sent:* Wednesday, September 12, 2012 1:55 PM > *To:* Ouriel, Boaz > *Cc:* cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > *Subject:* Re:
2013 Jan 24
1
[LLVMdev] [cfe-dev] OpenCL SPIR/NVPTX code generation
Hello everyone, Thanks a lot for the help. -target nvptx worked great with llvm-3.2. However it gives error with -target spir. LLVM/Clang trunk although works good for both options ( probably because spir is still work in progress ). Thanks again. - Ankur On Thu, Jan 24, 2013 at 12:43 PM, Benyei, Guy <guy.benyei at intel.com> wrote: > Hi Jordan,**** > > You’re right, and
2013 Jan 23
2
[LLVMdev] [cfe-dev] OpenCL SPIR/NVPTX code generation
On Jan 23, 2013, at 4:04 , "Benyei, Guy" <guy.benyei at intel.com> wrote: > Hi Ankur, > Since you use –Xclang, the clang executable passes multiple triples to “clang -cc1”. You can see that if you add the -v option. I’m sure there is someone here who can explain it better than I… > Anyhow, I think you better use clang -cc1. Make sure -cc1 is the first command line option
2013 Jan 24
0
[LLVMdev] [cfe-dev] OpenCL SPIR/NVPTX code generation
Hi Jordan, You're right, and the driver -target option works perfectly with the SPIR triples. Thanks Guy Benyei [email_signature_guy_new2] From: Jordan Rose [mailto:jordan_rose at apple.com] Sent: Wednesday, January 23, 2013 19:47 To: Benyei, Guy Cc: ankur deshwal; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu Subject: Re: [cfe-dev] OpenCL SPIR/NVPTX code generation On Jan 23, 2013, at
2013 Jan 23
3
[LLVMdev] OpenCL SPIR/NVPTX code generation
Hi Guy, Thanks a lot for the clarification. I tried using the triple for SPIR as $ clang -x cl -fno-builtin -emit-llvm -c -Xclang -triple -Xclang spir-unknown-unknown Simple_Kernel.cl However I get the following error. error: unknown target triple 'spir-unknown-unknown', please use -triple or -arch I also tried with triple nvptx-unknown-unknown clang -x cl -fno-builtin -emit-llvm -S
2016 Sep 12
2
builtins name mangling in SPIR 2.0
Hi all, According to the SPIR 2.0 spec[1], the name of OpenCL builtins are mangled. However, when I compile OpenCl code with Clang 3.9 with the "spir64-unknown-unknown" target, Clang generates IR without mangling the builtins, e.g. for: __kernel void input_zip_int(__global int *in0) { *in0 = get_global_id(0); } clang generates: define spir_kernel void @input_zip_int(i32
2016 Sep 12
2
builtins name mangling in SPIR 2.0
Thanks a lot. On Mon, Sep 12, 2016 at 1:42 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > If you use the default header file under clang/lib/Headers/opencl-c.h, > get_global_id will be mangled. > > > > If you want to declare get_global_id in your own header, add > __attribute__((overloadable)), then it will be mangled. > > > > Sam > > > >
2016 Sep 16
2
builtins name mangling in SPIR 2.0
+ Alexey Anastasia According to SPIR spec v1.2 s2.10.3 2.10.3 The printf function The printf function is supported, and is mangled according to its prototype as follows: int printf(constant char * restrict fmt, ... ) Note that the ellipsis formal argument (...) is mangled to argument type specifier z It seems printf should be mangled. Alexey/Anastasia, What do you think? Thanks. Sam From:
2013 Jan 23
0
[LLVMdev] OpenCL SPIR/NVPTX code generation
Hi Ankur, Since you use -Xclang, the clang executable passes multiple triples to "clang -cc1". You can see that if you add the -v option. I'm sure there is someone here who can explain it better than I... Anyhow, I think you better use clang -cc1. Make sure -cc1 is the first command line option you use. $ clang -cc1 -fno-builtin -emit-llvm-bc -triple spir-unknown-unknown
2016 Sep 18
2
builtins name mangling in SPIR 2.0
I don't see any problem mangling it to be honest even though there seems to be only one prototype anyways. We could add restrict in as well. Cheers, Anastasia ________________________________ From: Hongbin Zheng <etherzhhb at gmail.com> Sent: 17 September 2016 05:32:54 To: Liu, Yaxun (Sam) Cc: cfe-dev at lists.llvm.org; llvm-dev; Bader, Alexey (alexey.bader at intel.com); Anastasia