similar to: [LLVMdev] [cfe-dev] OpenCL support

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Peter Collingbourne > Sent: Monday, December 06, 2010 2:56 PM > To: David Neto > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] [cfe-dev] OpenCL support > > Hi David, > > On Mon, Dec 06, 2010 at 11:14:42AM -0500,

On Mon, Dec 6, 2010 at 6:16 PM, 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 Peter Collingbourne >> Sent: Monday, December 06, 2010 2:56 PM >> To: David Neto >> Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu >>

> -----Original Message----- > From: David Neto [mailto:dneto.llvm at gmail.com] > Sent: Tuesday, December 07, 2010 1:03 PM > To: Villmow, Micah > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [cfe-dev] [LLVMdev] OpenCL support > > On Mon, Dec 6, 2010 at 6:16 PM, Villmow, Micah <Micah.Villmow at amd.com> > wrote: > >> -----Original

On Fri, Dec 17, 2010 at 04:21:18PM -0500, David Neto wrote: > However we record the fact that a function is a kernel, the mechanism > should handle the case of a kernel calling another kernel. > Recall that a kernel called by another kernel behaves more like a > regular function. For example it doesn't have workspace iteration > automatically applied to it; rather it just

> From: Peter Collingbourne [mailto:peter at pcc.me.uk] > Sent: 20 December 2010 20:11 > As with __local variables, it may be that "kernelness" cannot be > represented in a standard form in LLVM. For example on a CPU a > kernel function may have an additional parameter which is a pointer to > __local memory space, which would not be necessary on GPUs. Then in >

On Fri, Dec 17, 2010 at 5:16 PM, Nick Lewycky <nlewycky at google.com> wrote: > Being discardable is a design point of metadata. You might add something > else to support this, but it won't be metadata. > Why are you trying to preserve "kernel"-ness into the LLVM IR? What > semantics does it have? What does __kernel actually mean to the optimizers > and code

On Thu, Oct 13, 2011 at 04:14:09PM -0400, Justin Holewinski wrote: > On Thu, Oct 13, 2011 at 11:57 AM, Peter Collingbourne <peter at pcc.me.uk>wrote: > > > Hi Justin, > > > > Thanks for bringing this up, I think it's important to discuss > > these issues here. > > > > On Thu, Oct 13, 2011 at 09:46:28AM -0400, Justin Holewinski wrote: > >

On Fri, Oct 14, 2011 at 10:40 AM, Peter Collingbourne <peter at pcc.me.uk>wrote: > On Thu, Oct 13, 2011 at 04:14:09PM -0400, Justin Holewinski wrote: > > On Thu, Oct 13, 2011 at 11:57 AM, Peter Collingbourne <peter at pcc.me.uk > >wrote: > > > > > Hi Justin, > > > > > > Thanks for bringing this up, I think it's important to discuss >

On Tue, Mar 1, 2011 at 4:06 PM, David Neto wrote: > On Mon, Feb 28, 2011 at 4:41 PM, Peter Collingbourne wrote: >> >> The more I think about it, the more I become uncomfortable with the >> concept of language-specific address spaces in LLVM.  These are the >> main issues I see with language-specific address spaces: > > ... > >> Instead of language-specific

On Thu, Oct 13, 2011 at 11:57 AM, Peter Collingbourne <peter at pcc.me.uk>wrote: > Hi Justin, > > Thanks for bringing this up, I think it's important to discuss > these issues here. > > On Thu, Oct 13, 2011 at 09:46:28AM -0400, Justin Holewinski wrote: > > It is becoming increasingly clear to me that LLVM address spaces are not > the > > general solution

However we record the fact that a function is a kernel, the mechanism should handle the case of a kernel calling another kernel. Recall that a kernel called by another kernel behaves more like a regular function. For example it doesn't have workspace iteration automatically applied to it; rather it just adopts the work item of the caller. About using a calling convention to mark a function

Hi, Tanya and I also prefer the extended TBAA solution as it naturally fits with LLVM. From my understanding of TBAA, it seems to provide the power to describe the relationship between address spaces for alias analysis, i.e., it can describe if two address spaces are disjoint or one may nest within another. For OpenCL, it is most useful to indicate that address spaces are disjoint from the

On Tue, Dec 21, 2010 at 07:17:40PM -0000, Anton Lokhmotov wrote: > > From: Peter Collingbourne [mailto:peter at pcc.me.uk] > > Sent: 20 December 2010 20:11 > > As with __local variables, it may be that "kernelness" cannot be > > represented in a standard form in LLVM. For example on a CPU a > > kernel function may have an additional parameter which is a

The problem I want to address in this discussion is the representation of OpenCL/CUDA memory spaces in LLVM IR. As support for OpenCL and CUDA mature within Clang, it is important that we provide a way to represent memory spaces in a way that is (1) sufficiently generic that other language front-ends can easily emit the needed annotations, and (2) sufficiently specific that LLVM optimization

On Mon, Feb 28, 2011 at 4:41 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > The more I think about it, the more I become uncomfortable with the > concept of language-specific address spaces in LLVM.  These are the > main issues I see with language-specific address spaces: ... > Instead of language-specific address spaces, each target should > concentrate on

On Fri, Feb 25, 2011 at 02:55:33PM -0500, Ken Dyck wrote: > The address space mechanism is used by some code generators to > differentiate between physical memory spaces. The PIC16 code generator > uses address spaces 0 and 1 to select between its RAM and ROM spaces. > And X86 uses address space 256 for GS and 257 for FS. In the back end > for a dual-harvard DSP that I've been

Justin, Out of these options, I would take the metadata approach for AA support. This doesn't solve the problem of different frontend/backends choosing different address space representations for the same language, but is the correct approach for providing extra information to the optimizations. The issue about memory spaces in general is a little different. For example, based on the

On Thu, Dec 16, 2010 at 06:16:25PM -0000, Anton Lokhmotov wrote: > Mike Gist wrote: > > You could also consider placing all kernel functions in a 'kernel' > > section, or adding a function attribute for kernels. > Unlike in Clang, function attribute bit-fields in LLVM are pretty crowded > (only couple of bits are unused?). Besides, we do not want to represent >

Hi Justin, Thanks for bringing this up, I think it's important to discuss these issues here. On Thu, Oct 13, 2011 at 09:46:28AM -0400, Justin Holewinski wrote: > It is becoming increasingly clear to me that LLVM address spaces are not the > general solution to OpenCL/CUDA memory spaces. They are a convenient hack to > get things working in the short term, but I think a more

looks good here. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Anton Lokhmotov > Sent: Thursday, May 17, 2012 4:51 AM > To: 'David Neto' > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] [PATCH] OpenCL half support > > Hi David, > > Many thanks for the comments! > >