search for: dneto

..._________________ From: Marco Antognini <Marco.Antognini at arm.com> Sent: 18 October 2019 14:42 To: Anastasia Stulova <Anastasia.Stulova at arm.com>; Simone Atzeni via llvm-dev <llvm-dev at lists.llvm.org>; clang developer list <cfe-dev at lists.llvm.org> Cc: David Neto <dneto at google.com>; nd <nd at arm.com>; Diego Novillo <dnovillo at google.com> Subject: Re: US LLVM Dev Meeting 2019 - Round Table - Challenges using LLVM for GPU compilation Dear all, Could I suggest adding one more topic to the list related to GPUs? We have just published a prototype...

Dear all, I would like announce a round table planned for the upcoming LLVM Dev meeting next week that will cover various topics related to the use of LLVM in the compiler stacks for the GPUs. Here is the initial list of discussion topics: - Canonicalization vs. GPUs: Type mutation; - Control flow mutation (graphics shaders are more sensitive to this); - Divergence/reconvergence sensitivity;

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

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

I have filed a number of problem reports about getting the LLVM test infrastructure working for an environment with: Windows + MSVC9 + Cmake + NMake makefiles + MKS. (MKS provides unix-like tools for Windows, but based on very old versions, so they have quirky or minimal compatibility with GNU tools.) http://llvm.org/bugs/show_bug.cgi?id=9689 - Fix Cmake generation of compile_cxx for MSVC -

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

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