similar to: [LLVMdev] Function-level metadata for OpenCL (was Re: OpenCL support)

On 16 December 2010 14:33, Peter Collingbourne <peter at pcc.me.uk> wrote: > 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

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

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

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

> -----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. > > > +enum OpenCLAddressSpace { > > + OPENCL_PRIVATE = 0, > > + OPENCL_GLOBAL = 1, > > + OPENCL_LOCAL

That is a good question and I don't know. The optimization is defined include/llvm/Analysis/ObjectUtils.h. If I enable that for weak_odr + unnamed_addr, no tests are failing so I guess it is a safe optimization? :) It is probably because the autohide optimization is targeted at c++ templates and inline functions and we know they have linkonce_odr linkage, which suggests whoever uses this

There should be no semantic difference between linkonce_odr and weak_odr, except that weak_odr is non-discardable. Why doesn't the autohide optimization work just as well on weak_odr + unnamed_addr as linkonce_odr + unnamed_addr? On Tue, Feb 6, 2018 at 5:35 PM, Steven Wu via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I recently found that thinLTO doesn't deal

On Thu, Sep 08, 2011 at 11:15:06AM -0500, Villmow, Micah wrote: > Peter, > Is there a way to make this flag globally available? Metadata can be fairly expensive to handle at each node when in many cases it is a global flag and not a per operation flag. There are two main reasons why I think we shouldn't go for global flags: 1) It becomes difficult if not impossible to correctly link

Hi, I recently found that thinLTO doesn't deal with globals that has linkonce_odr and unnamed_addr (for macho at least) because it prohibits the autohide optimization during link time. In LLVM, we tagged a global linkonce_odr and unnamed_addr to indicate to the linker can hide them from symbol table if they were picked (aka, linkonce_odr_auto_hide linkage). It is very commonly used for some

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

>From looking at the code, it seems like LLVM is basically opting MachO into -fvisibility-inlines-hidden all the time, i.e. if the function is linkonce, it's discardable, so mark it hidden to pretend the compiler inlined it and discarded it. However, this isn't conforming, because the addresses of inline functions will no longer compare equal across DSOs. Realistically, nobody cares

Peter, Is there a way to make this flag globally available? Metadata can be fairly expensive to handle at each node when in many cases it is a global flag and not a per operation flag. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Robert Quill > Sent: Thursday, September 08, 2011 3:24 AM > To: Peter

Hi Peter, This sounds like I really good idea. One thing that did occur to me though from an OpenCL point of view is that ULP accuracy requirements can differ for embedded and full profile so that may need to be handled somehow. Thanks, Rob On Wed, 2011-09-07 at 21:55 +0100, Peter Collingbourne wrote: > Hi, > > This is my proposal to add floating point accuracy support to LLVM. >

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

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:

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]

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

We are working on getting the documentation cleaned up to the point where it can be released. If you look at the test cases, you can infer what needs to be done. Basically since this is targeted for OpenCL, we annotate OpenCL kernels slightly different than normal functions and that is what causes the code to be generated. That being said, on my list of things to do is fix this so that any

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