similar to: [LLVMdev] [PATCH] OpenCL support - update on keywords

> > > > +enum OpenCLAddressSpace { > > > > + OPENCL_PRIVATE = 0, > > > > + OPENCL_GLOBAL = 1, > > > > + OPENCL_LOCAL = 2, > > > > + OPENCL_CONSTANT = 3 > > > > +}; > -----Original Message----- > From: Villmow, Micah [mailto:Micah.Villmow at amd.com] > > Anton, > Would there be any issue with switching

Anton, Would there be any issue with switching the ordering of constant and local? > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Anton Lokhmotov > Sent: Friday, February 18, 2011 7:27 AM > To: 'Peter Collingbourne' > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: [LLVMdev]

The problem is that we use the ordering private, global, constant and local, and this is the same ordering that is used on Apple as well. As we already have OpenCL binaries out in public, making the change is problematic as we want to keep backward compatibility at all costs. Thanks, Micah > -----Original Message----- > From: Anton Lokhmotov [mailto:Anton.Lokhmotov at arm.com] > Sent:

On Fri, Feb 18, 2011 at 03:27:13PM -0000, Anton Lokhmotov wrote: > > -----Original Message----- > > From: Peter Collingbourne [mailto:peter at pcc.me.uk] > > Sent: 04 January 2011 21:42 > > To: Anton Lokhmotov > > Cc: cfe-dev at cs.uiuc.edu > > Subject: Re: OpenCL support > > > > Here are my comments on the second patch. > > > > >

> -----Original Message----- > From: Michele Scandale [mailto:michele.scandale at gmail.com] > Sent: Saturday, August 10, 2013 5:30 AM > To: Micah Villmow > Cc: James Courtier-Dutton; LLVM Developers Mailing List > Subject: Re: [LLVMdev] Address space extension > > > [Micah Villmow] The backends won't understand your address space > > mapping. The backends

> [Micah Villmow] The backends won't understand your address space mapping. The backends should expose their address spaces that they support, their sizes and their overall semantics. It should be documented just like the calling convention is documented. It is then the job of the frontend to map whatever source language address spaces are used onto the correct address spaces for the

On Thu, Feb 24, 2011 at 1:14 PM, Anton Lokhmotov <Anton.Lokhmotov at arm.com> wrote: > Hi Peter, > > Many thanks for your prompt review. > >> I don't think we should include the word OpenCL in the name of this >> enum/header.  We may very well in the future want to define address >> space constants for other languages, which should not overlap with >>

On Mar 21, 2011, at 3:44 AM, Anton Lokhmotov wrote: >> Adding half float to LLVM IR is *only* reasonable if you have hardware >> that supports half float, or if you want to add softfloat operations >> for these. > Yes, our graphics hardware natively supports some fp16 arithmetic > operations. Ok. >> Just like C compilers need to know sizeof(long), sizeof(void*) and

On Mar 17, 2011, at 10:17 AM, Anton Lokhmotov wrote: > Hi Chris, > > So what do you think about this proposal? If you agree, it would be good to > include the patch into the 2.9 release (to avoid breaking compatibility > later). Hi Anton, I'm sorry I don't have the patch anymore. Please resend. It is too late for new features in 2.9 though. >> The last paragraph

On Aug 7, 2013, at 2:07 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 08/07/2013 01:52 PM, Michele Scandale wrote: >> >> IMHO this information should be a plus that could be *safely* ignored when not necessary and used where it can provide an improvement in optimizations. This does not necessary mean the the middle-end (and the back-ends) must be aware of the

On Mar 21, 2011, at 1:59 PM, Zhang, Chihong wrote: > Hi Chris, > > It is important for embedded/mobile computation to have efficient fp16 support, otherwise those users will suffer from the merging problem with their local LLVM with native fp16 type they add (locally). So we should either add full fp16 support as a basic floating point type or enhance the LLVM infrastructure to make

On Aug 7, 2013, at 2:54 PM, Michele Scandale <michele.scandale at gmail.com> wrote: >> I don’t know if CUDA has aliasing address spaces, but that would also be >> useful to consider. Something simple like this might work. Note i’m >> using the examples from the clang discussion, that is "1 = opencl/cuda >> global, 2 = opencl_local/cuda_shared, 3 = opencl/cuda

Hi Chris, It is important for embedded/mobile computation to have efficient fp16 support, otherwise those users will suffer from the merging problem with their local LLVM with native fp16 type they add (locally). So we should either add full fp16 support as a basic floating point type or enhance the LLVM infrastructure to make floating point type as scalable as int type. -Chihong -----Original

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Chris Lattner > Sent: Friday, March 18, 2011 1:15 PM > To: Anton.Lokhmotov at arm.com > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] [PATCH] OpenCL half support > > > On Mar 17, 2011, at 10:17 AM, Anton Lokhmotov wrote: > > > Hi

> 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 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

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! > >

On May 20, 2011, at 6:48 AM, Anton Lokhmotov wrote: > Hi Chris, > >> Sorry for dropping this. Can you resend your current patch? Lets just >> start and iterate on the llvm patch first. > Please find the LLVM patch attached. Hi Anton, This looks like a great start, but it needs a lot of testcases showing that these things constant fold, handle conversions correctly, and

> I don’t know if CUDA has aliasing address spaces, but that would also be > useful to consider. Something simple like this might work. Note i’m > using the examples from the clang discussion, that is "1 = opencl/cuda > global, 2 = opencl_local/cuda_shared, 3 = opencl/cuda constant" You are assuming that the target device has different physical address spaces (like, PTX

On Feb 23, 2011, at 10:01 AM, Anton Lokhmotov wrote: > Please find attached Clang/LLVM patches for supporting 'half' - the > half-precision floating-point type, which in particular is used in OpenCL C. > Please review. > > Background and motivation. Whilst the half type is defined by IEEE 754-2008 > as storage only (i.e. no arithmetic is supposed to be performed on