similar to: [LLVMdev] OpenCL support

On 26 August 2010 09:32, Krister Wombell <kuwerty at gmail.com> wrote: > I've also been looking at debugging with ELF and noticed the same problem as > Renato. I just sent a patch to llvmcommits that fixes the problem. > DW_at_stmt_list needs to emit a label(and therefore a relocation) for the > offset rather a constant 0, then the linker can fixup the offset as it >

On Aug 31, 2010, at 2:15 AM, Renato Golin wrote: > On 26 August 2010 09:32, Krister Wombell <kuwerty at gmail.com> wrote: >> I've also been looking at debugging with ELF and noticed the same problem as >> Renato. I just sent a patch to llvmcommits that fixes the problem. >> DW_at_stmt_list needs to emit a label(and therefore a relocation) for the >> offset

I've also been looking at debugging with ELF and noticed the same problem as Renato. I just sent a patch to llvmcommits that fixes the problem. DW_at_stmt_list needs to emit a label(and therefore a relocation) for the offset rather a constant 0, then the linker can fixup the offset as it shuffles object files around. Krister On Thu, Aug 26, 2010 at 5:11 AM, Renato Golin <rengolin at

> 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 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 26 Aug 2010, at 10:32, Krister Wombell wrote: > I've also been looking at debugging with ELF and noticed the same > problem as > Renato. I just sent a patch to llvmcommits that fixes the problem. > DW_at_stmt_list needs to emit a label(and therefore a relocation) > for the > offset rather a constant 0, then the linker can fixup the offset as it > shuffles object

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

Could someone please commit the attached patches? /* Approved by: - Anton Korobeynikov: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-May/049849.html - Micah Villmow: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-May/049848.html - David Neto: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-May/049705.html */ Many thanks, Anton. -----Original Message----- From: Anton Lokhmotov

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

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

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

Anton, would it be possible to add information to the documentation here: http://llvm.org/docs/BitCodeFormat.html > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Villmow, Micah > Sent: Thursday, May 17, 2012 9:04 AM > To: Anton.Lokhmotov at arm.com; 'David Neto' > Cc: llvmdev at cs.uiuc.edu >

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

I've got comments on the code change. The test cases look ok, but I haven't fully checked the math on the half-values. I checked with reference to trunk top-of-tree at revision 156617. I have not compiled the code. lib/AsmParser/LLLexer.cpp Adds support to parse format: 0xH<hexdigits> Tha 0xH format should be described in LangRef.html alongside 0xK<hex> and

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <br> <br> Villmow, Micah wrote: <blockquote

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

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

Sorry for the late reply, as I have been on vacation for awhile. One method which I haven't seen mentioned is to separate out the kernel semantics from the function definition. All the kernel attribute does is specify that this function is an entry point to the device from the host. So, why not just create a separate entry point that is only callable by the host and everything from the