similar to: Testing "normal" cross-compilers versus GPU backends

> -----Original Message----- > From: Mehdi Amini [mailto:mehdi.amini at apple.com] > Sent: Wednesday, September 02, 2015 7:10 PM > To: Robinson, Paul > Cc: llvm-dev at lists.llvm.org; tom at stellard.net; NAKAMURA Takumi > Subject: Re: Testing "normal" cross-compilers versus GPU backends > > Hi Paul, > > Thanks for the summary! > > > On Sep 2,

On Thu, Sep 03, 2015 at 02:07:54AM -0700, Mehdi Amini wrote: > > > On Sep 3, 2015, at 12:18 AM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: > > > > > > > >> -----Original Message----- > >> From: Mehdi Amini [mailto:mehdi.amini at apple.com] > >> Sent: Wednesday, September 02, 2015 7:10 PM > >> To: Robinson,

> On Sep 3, 2015, at 11:23 AM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: > > > >> -----Original Message----- >> From: Tom Stellard [mailto:tom at stellard.net] >> Sent: Thursday, September 03, 2015 7:31 AM >> To: Mehdi Amini >> Cc: Robinson, Paul; llvm-dev at lists.llvm.org; NAKAMURA Takumi >> Subject: Re: Testing

> On Sep 3, 2015, at 5:56 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: > > > >> -----Original Message----- >> From: Mehdi Amini [mailto:mehdi.amini at apple.com] >> Sent: Thursday, September 03, 2015 3:26 PM >> To: Robinson, Paul >> Cc: Tom Stellard; llvm-dev at lists.llvm.org; NAKAMURA Takumi >> Subject: Re: Testing

Hello everyone I was wondering, what the correct way of using an AMDGPU generated kernel code for OpenCL was. I am trying to provide Polly's GPGPU Code generation with the ability to run on different GPU devices, such as AMD GPUs. For NVIDIA, I simply retrieve a pre-compiled PTX string from the NVPTX backend and pass that to OpenCL's 'clCreateProgramWithBinary' function. However,

On 09/04/2015 10:25 AM, Robinson, Paul via llvm-dev wrote: > >> -----Original Message----- >> From: James Y Knight [mailto:jyknight at google.com] >> Sent: Friday, September 04, 2015 10:12 AM >> To: Mehdi Amini; Mehdi Amini via llvm-dev >> Cc: Robinson, Paul >> Subject: Re: [llvm-dev] Testing "normal" cross-compilers versus GPU >> backends

>>> The Hexagon precedent is interesting; Krzysztof said they set the default >>> triple, and didn't have to xfail all that much stuff. Searching the tree, >>> I find exactly 7 individual tests marked XFAIL: hexagon, plus it disables >>> all of ExecutionEngine, and turns off the 'object-emission' feature. >>> >>> I'm curious

> > Mehdi - Could you list a couple of the features that show up in generic > tests which your target doesn't support by design? After reading through > the discussion to this point, I don't really have a feel for that. > Additionally, do you have any sense for how common that set is across GPU > targets? > > This is what I was referring to in my last email: >

> On Sep 4, 2015, at 10:19 AM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: > >>>>> Krzysztof suggested much the same thing that I think you are currently >>>>> doing, which is deliberately configure a default triple but exclude >> the >>>>> corresponding backend. >>>> >>>> You and Takumi were

On 09/29/2015 04:19 PM, Tom Stellard via llvm-dev wrote: > On Tue, Sep 29, 2015 at 01:20:57PM +0000, Paweł Bylica via llvm-dev wrote: >> Hi LLVM, >> >> I would like to compile OpenCL kernel for a specific AMD GPU target. Is it >> possible with the current clang/LLVM? >> >> I started by using `clang -x cl` but it looks like at least some OpenCL >>

Finally I kind of modified llvm to generate assembly that can run on AMDGPU pro drivers. One problem is the performance of the code generated by llvm is about 10% slower than amdgpu's online compiler. Anything I can tune the performance up the performance of llvm?\ Thanks! On Tue, Sep 4, 2018 at 9:23 AM 董昌道 <dongchangdao at gmail.com> wrote: > I am writing a miner of crypto

I have been working for extending test coverage for years. Nowadays, I have several cross-testing (target != host). See http://bb.pgr.jp/console Each of them (test-*-linux) is doing; - Assume a preceding builder passes with warming ccache. - All compilation units will hit ccache whenever the tree is built before lit. - Almost all compilation units will hit ccache except for Host.cpp when

Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> writes: > Hi Varun, > > I'm definitely in favour of making -v more useful like this. > > On Thu, 12 Sep 2019 at 19:31, Varun Gandhi via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Option 2 (less deviation from status quo): >> -v: Adopts behavior of -vvv from Option 1. :) >> -vv: Same

Hi Mr. Liu, Thanks for your quick reply. I compiled the code with the libclc_trunk and linked the bitcode file under $LIBCLC_DIR/built_libs/tahiti-amdgcn--.bc. After looking into the libclc, it is currently using the new workitem intrinsics (commit ba9858caa1e927a6fcc601e3466faa693835db5e). In the linked bitcode ($LIBCLC_DIR/built_libs/tahiti-amdgcn--.bc), it has the following code segment,

Hi, I'm finally going to do the R600->AMDGPU rename this Friday. This is something I originally proposed last July [1], but had to put off in order to avoid creating really bad merge headaches for some users. The only change from my original proposal is that I'll just keep the existing r600 and amdgcn triples rather than adding a new one for amdgpu. If anyone has any strong

Hi all, I intend to add address sanitizer (un)poison calls to Recycler and ArrayRecycler since I spent a few hours tracking down a bug in the AMDGPU backend that turned out to be a use-after-free that would have been detected by asan if it weren't for the Recycler. See https://reviews.llvm.org/D25313. Naturally, such a change exposes a bunch of bugs or things that are dodgy and happen

Dear Developers, I compiled a OpenCL kernel before (on Nov. last year) like __kernel void g(__global float* array) { array[get_global_id(0)] = 1; } with libclc, which would originally use the instrinsics like llvm.r600.read.local.size.x(). I executed the generated object file with one version of the hsa-runtime [1] provided by Mr. Stellard, when there was more than one workgroup, the output

On Sat, Dec 1, 2012 at 1:06 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Fri, Nov 30, 2012 at 8:04 PM, Chris Lattner <clattner at apple.com> wrote: > >> I'm ok with this in principle, but how about with the nuance that some >> tests (eg test/codegen) explicitly opt into march=native? >> > > I'd really like the default behavior to be

As part of trying to fix PR30610 (ThinLTO with module inline asm), I wanted to add an assert that we have a Target and an MCAsmParser when we have non-null module inline asm in IRObjectFile::CollectAsmUndefinedRefs. Otherwise it silently fails to parse the module inline asm, which I initially found when trying to add an 'opt' based test for my fix (because 'opt' wasn't

On Mon, Dec 3, 2012 at 10:47 AM, Daniel Dunbar <daniel at zuster.org> wrote: > On Sat, Dec 1, 2012 at 1:06 AM, Chandler Carruth <chandlerc at google.com> > wrote: >> >> On Fri, Nov 30, 2012 at 8:04 PM, Chris Lattner <clattner at apple.com> wrote: >>> >>> I'm ok with this in principle, but how about with the nuance that some >>>