similar to: [LLVMdev] Null pointers with a non-0 representation

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] Null pointers with a non-0 representation"

2013 Nov 17
3
[LLVMdev] Null pointers with a non-0 representation
Hi Micah, Thanks a lot for the reference. Unfortunately, it looks like the discussion there is dealing with a somewhat different issue - modeling OpenCL address spaces. It's true that the null pointer issue may arise in a similar context (e.g. null pointers in different address spaces may have different internal representations), but it's not entirely related. Or have I missed something
2013 Nov 17
0
[LLVMdev] Null pointers with a non-0 representation
I ran into the same problem in OpenCL with Local/Private address spaces and I believe it was discussed here in the past. So I would suggest looking through the archives as I believe some of your questions are answered there. This post might be a good starting point: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044101.html Also the SPIR provisional spec as of last November deals with
2013 Nov 19
0
[LLVMdev] Null pointers with a non-0 representation
+llvm-dev Yes. The question then becomes, does LLVM handle the case where the cast of the value 0 to a non-void* pointer? Think of this case: int *ptr = (int*)0; based on a strict reading of the spec, ptr itself technically is not the null pointer constant. If ptr points to an object in the local address space in OpenCL, or any address space where 0 is a valid address and memory exists, does
2013 Nov 19
1
[LLVMdev] Null pointers with a non-0 representation
On Nov 19, 2013, at 10:52, Micah Villmow <micah.villmow at smachines.com> wrote: > +llvm-dev > Yes. The question then becomes, does LLVM handle the case where the cast of the value 0 to a non-void* pointer? > > Think of this case: > int *ptr = (int*)0; > > based on a strict reading of the spec, ptr itself technically is not the null pointer constant. Not true, the
2012 Sep 12
2
[LLVMdev] [cfe-dev] SPIR provisional specification is now available in the Khronos website
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
2012 Sep 11
2
[LLVMdev] [cfe-dev] SPIR provisional specification is now available in the Khronos website
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
2012 Sep 12
0
[LLVMdev] [cfe-dev] 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
2012 Sep 28
4
[LLVMdev] [pocl-devel] [cfe-dev] SPIR provisional specification is now available in the Khronos website
Carlos, AMD's OpenCL implementation(both CPU and GPU) has worked for years with the way SPIR represents locals. If there is problems with the representation then it is an implementation issue. One of the issues with using extra kernel arguments is that it requires extra validation and complexity at the runtime level that is not needed if it is handled internally by the compiler. That being
2012 Sep 12
0
[LLVMdev] [cfe-dev] 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
2012 Sep 11
2
[LLVMdev] SPIR provisional specifciation is now available in the Khronos website
> -----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, >
2012 Sep 28
0
[LLVMdev] [pocl-devel] [cfe-dev] SPIR provisional specification is now available in the Khronos website
Micah, You're saying it works for you, but Clang doesn't currently anywhere near the range of horrible constantexpr constructs it is possible to create. You can "get by" at the moment with just handling ConstantGEPs, because of the way Clang works. But SPIR isn't restricted to Clang, and the problem is that it is *possible* (although not probable, or nice, but that is
2012 Sep 11
0
[LLVMdev] [cfe-dev] 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
2012 Sep 11
4
[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
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 11
0
[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? (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
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:
2012 Sep 17
1
[LLVMdev] SPIR provisional specifciation is now available in the Khronos website
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
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 06
2
[LLVMdev] "SPIR" ? A Standard Portable IR for OpenCL Kernel Language
On Sep 6, 2012, at 4:33 PM, "Ouriel, Boaz" <boaz.ouriel at intel.com> wrote: > **** 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
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