similar to: [LLVMdev] [PATCH] R600 - Fix zero extend of i1

Hi, I've prepared patches for both LLVM and Clang to change the datalayout for R600. This may seem like a bold move, but I think it is warranted. R600/SI is a strange architecture in that it uses 64bit pointers but does not support 64 bit arithmetic except for load/store operations that roughly map onto getelementptr. The current datalayout for r600 includes n32:64, which is odd

> This patch looks good, but you need to add a test case. You can add it > to the file test/CodeGen/R600/zero_extend.ll Version 2 of patch attached which includes test case. -Jon -------------- next part --------------

Hi Tom, Matt, I'm working on a project that needs few coherent atomic operations (HSA mode: load, store, compare-and-swap) for std::atomic_uint in HCC. the attached patch implements atomic compare and swap for SI+ (untested). I tried to stay within what was available, but there are few issues that I was unsure how to address: 1.) it currently uses v2i32 for both input and output. This

On Fri, Mar 25, 2016 at 02:22:11PM -0400, Jan Vesely wrote: > Hi Tom, Matt, > > I'm working on a project that needs few coherent atomic operations (HSA > mode: load, store, compare-and-swap) for std::atomic_uint in HCC. > > the attached patch implements atomic compare and swap for SI+ > (untested). I tried to stay within what was available, but there are > few issues

Hello, It looks like that in the DAG matcher, the DAG has a xor with '-1' for checking a true value vector for instance, %cmp4.i = icmp ne <8 x i32> %6, %5 %7 = xor <8 x i1> %cmp4.i, <i1 true, i1 true, i1 true, i1 true, i1 true, i1 true, i1 true, i1 true> [use of %7] results in vector of '-1' in the DAG. This also seems the reason why LLVM's vnot PatFrag

Hi Chris, Ben and Dmitri have completed coding style reviews for the R600 backend, and I have made all the requested changes. What else needs to be done before we can commit this backend to the main tree? Thanks, Tom On Thu, Nov 29, 2012 at 05:09:57PM +0100, Benjamin Kramer wrote: > > > $ grep -r '^[ ]*{$' > > Otherwise I don't see anything else that needs fixing

On Nov 29, 2012, at 2:13 PM, Tom Stellard <tom at stellard.net> wrote: > Hi Dimitri, > > Thanks for taking a look at the code. > > I went ahead and made all of these changes, and I reviewed the doxygen section > of the Coding Standards document and updated the comments as well. > I also fixed the issue mentioned by Ben with braces on their own line. > >

Chris, > On Nov 29, 2012, at 2:13 PM, Tom Stellard <tom at stellard.net> wrote: >> Hi Dimitri, >> >> Thanks for taking a look at the code. >> >> I went ahead and made all of these changes, and I reviewed the doxygen section >> of the Coding Standards document and updated the comments as well. >> I also fixed the issue mentioned by Ben with

On Mon, Dec 10, 2012 at 11:03:16PM -0800, Chris Lattner wrote: > On Nov 29, 2012, at 2:13 PM, Tom Stellard <tom at stellard.net> wrote: > > Hi Dimitri, > > > > Thanks for taking a look at the code. > > > > I went ahead and made all of these changes, and I reviewed the doxygen section > > of the Coding Standards document and updated the comments as

Hi, I would like to assume code ownership of the R600 backend. Does anyone object? Thanks, Tom Stellard

greetings I am new to this list. I have recently compiled llvm-3.3 from sources. My machine has these: --cpu -amd64 --os- clbfs 64bit -linux3 series kernel --C/C++ compiler -modern versions gcc My preferred build tool is cmake. llvm is needed for MesaLib and the autotools build of llvm allows this option:- --enable-experimental-targets=R600 ( for example described here:

"lux-integ" <lux-integ at btconnect.com> writes: [snip] > So in a nutshell I would be grateful for some advice on how one enables this > option in a cmake build of llvm-3.(2,3,4) R600 was added to the list of known targets on the top-level CMakeLists.txt on June 22. So you can grab the LLVM development sources from svn or git and it should work (TM). If you wish to use

> Is that safely portable? ie is it required that pre-C++11 std:vector be implemented such that the data is stored contiguously in a realloc'd array? Yep. Very first paragraph of the std::vector description (23.2.4p1): " The elements of a vector are stored contiguously, meaning that if v is a vector<T, Allocator> where T is some type other than bool, then it obeys the identity

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, Now that the 3.5 branch has been made, I would like to propose renaming the R600 target to AMDGPU. R600 is the name of an AMDGPU GPU that was released about 8 years ago. The R600 backend supports this GPU and also all other GPUs which have been made since then. When people see the name R600 they often assume that only the older GPU family is supported which is not true. The reason that the

On Nov 26, 2013, at 1:41, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Can't you just use &Ops[0] ? Is that safely portable? ie is it required that pre-C++11 std:vector be implemented such that the data is stored contiguously in a realloc'd array? While I'm not sure anyone would do this (so perhaps the point is moot), it seems that one could use

Can't you just use &Ops[0] ? On Tue, Nov 26, 2013 at 12:03 PM, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote: > Hi Christian, > > Ryan just reported to me that llvm-3.4 is no longer building on OS X Leopard (https://trac.macports.org/ticket/41548). It seems the issue is with a commit that you made back in April (referenced below) which added this to

On Thu, Nov 29, 2012 at 06:28:15PM +0200, Dmitri Gribenko wrote: > On Tue, Nov 27, 2012 at 12:37 AM, Tom Stellard <tom at stellard.net> wrote: > > Assuming I caught all the coding style mistakes you pointed out, what > > else needs to be done to be able to commit this code? > > Hello Tom, > > There are still a few classes of coding style issues... > > +

On Tue, Nov 27, 2012 at 12:37 AM, Tom Stellard <tom at stellard.net> wrote: > Assuming I caught all the coding style mistakes you pointed out, what > else needs to be done to be able to commit this code? Hello Tom, There are still a few classes of coding style issues... + /// CreateLiveInRegister - Helper function that adds Reg to the LiveIn list + /// of the DAG's

On Mon, Mar 26, 2012 at 01:22:01PM -0400, Villmow, Micah wrote: > Tom, > Two things. One is missing tests. I have some I could send you, but they are mainly OpenCL based for the AMDIL backend, not for the R600. > I've started working on the tests, and I've pushed a few up to my llvm repo. I can add the AMDIL tests too if you want to send them. I think they will be helpful.