Hi all, i'm trying to compile some small ANSI C benchmarks to PTX assembly. For this purpose, I'm using the NVPTX backend, introduced in the LLVM 3.2 release. It appears that certain LLVM constructs cannot be compiled to PTX. The problems mostly deal with handling of arrays. I also don't get any debug info when these problems. I use "llc" for compiling regular .ll files to PTX using the "nvptx" backend. The llc options are as follows (omitting these options also present the same problems): -nacdrvtest -asm-verbose -stats -print-before-all -print-after-all -time-passes 1. Only programs that make no use of arrays appear to always be processed correctly by llc (nvptx target). Some programs using arrays, make llc "hang" (runs endlessly). 2. One small C function exposing this behavior is as follows: // start here int arrtest (int x, int y) { unsigned char b[3]={0x10,0x30,0x55}; b[0] = (255 - b[x]) + b[y]; // doesn't work! // b[0] = (255 - b[0]) + b[1]; // works b[1] = x - y; b[2] = x * y; return b[0]; } // end here 3. A change that makes this function compilable (also visible in the comments) Change: b[0] = (255 - b[x]) + b[y]; to: b[0] = (255 - b[0]) + b[1]; Similarly, even the use of a single variable indexing (e.g. b[x]) doesn't work. Please note that if variable indexing is not used, then PTX assembly is generated. The problems seems related to the support/handling of variable indexing. However, the same code is always processed by other target backends (x86, mips). Is this behavior expected by the NVPTX backend? I understand that PTX is primarily targeted by OpenCL, however I would expect that the backend would issue some warnings on unimplemented features and not just run endlessly with no messages whatsoever. Best regards Nikolaos Kavvadias
The issue you're seeing is actually a problem with clang integration. Generally, clang does not understand all of the conventions required by the NVPTX back-end, and compilation from general C may not always work. In this case, it's the local array "b" that is the problem. Clang pulls this out into the global scope, but keeps it in address space 0. In the back-end, address space 0 is the PTX generic address space and global variables cannot use it. The index computations are not causing this issue. The following change would work: // start here __attribute__((address_space(3))) static unsigned char b[3]={0x10,0x30,0x55}; int arrtest (int x, int y) { b[0] = (255 - b[x]) + b[y]; // now it works! // b[0] = (255 - b[0]) + b[1]; // works b[1] = x - y; b[2] = x * y; return b[0]; } // end here If you compile LLVM in debug mode, you would have seen a failure about an unknown address space. I just committed a change in r174808 that emits a user-visible error for address space issues. I understand that there is a lack of documentation on the proper use of this back-end, and this is something I am working on rectifying. GPU targets place additional restrictions and conventions on compilers, and they often require some level of custom handling. In this case, you need to be careful how you use address spaces. You're not really doing anything wrong, clang was just never taught how to handle this case for NVPTX. On Sat, Feb 9, 2013 at 6:45 AM, <nkavv at physics.auth.gr> wrote:> Hi all, > > i'm trying to compile some small ANSI C benchmarks to PTX assembly. For > this purpose, I'm using the NVPTX backend, introduced in the LLVM 3.2 > release. > > It appears that certain LLVM constructs cannot be compiled to PTX. The > problems mostly deal with handling of arrays. I also don't get any debug > info when these problems. > > I use "llc" for compiling regular .ll files to PTX using the "nvptx" > backend. The llc options are as follows (omitting these options also > present the same problems): > > -nacdrvtest -asm-verbose -stats -print-before-all -print-after-all > -time-passes > > 1. Only programs that make no use of arrays appear to always be processed > correctly by llc (nvptx target). Some programs using arrays, make llc > "hang" (runs endlessly). > > 2. One small C function exposing this behavior is as follows: > > // start here > int arrtest (int x, int y) { > unsigned char b[3]={0x10,0x30,0x55}; > b[0] = (255 - b[x]) + b[y]; // doesn't work! > // b[0] = (255 - b[0]) + b[1]; // works > b[1] = x - y; > b[2] = x * y; > return b[0]; > } > // end here > > 3. A change that makes this function compilable (also visible in the > comments) > > Change: > b[0] = (255 - b[x]) + b[y]; > to: > b[0] = (255 - b[0]) + b[1]; > > Similarly, even the use of a single variable indexing (e.g. b[x]) doesn't > work. > > Please note that if variable indexing is not used, then PTX assembly is > generated. The problems seems related to the support/handling of variable > indexing. > > However, the same code is always processed by other target backends (x86, > mips). > > Is this behavior expected by the NVPTX backend? > > I understand that PTX is primarily targeted by OpenCL, however I would > expect that the backend would issue some warnings on unimplemented features > and not just run endlessly with no messages whatsoever. > > Best regards > Nikolaos Kavvadias > > > > ______________________________**_________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu llvm.cs.uiuc.edu > lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >-- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20130209/120f3305/attachment.html>
Thanks Justin for your prompt response.> The following change would work: > > // start here > __attribute__((address_space(3))) > static unsigned char b[3]={0x10,0x30,0x55}; > > int arrtest (int x, int y) { > b[0] = (255 - b[x]) + b[y]; // now it works! > // b[0] = (255 - b[0]) + b[1]; // works > b[1] = x - y; > b[2] = x * y; > return b[0]; > } > // end hereThanks, I will attempt to use this principle to my other small codes.> If you compile LLVM in debug mode, you would have seen a failure about an > unknown address space. I just committed a change in r174808 that emits a > user-visible error for address space issues.Indeed, I compiled LLVM in Release mode, so for this reason execution of llc appears to be hanging. I guess a Debug mode is always handy.> I understand that there is a lack of documentation on the proper use of > this back-end, and this is something I am working on rectifying. GPU > targets place additional restrictions and conventions on compilers, and > they often require some level of custom handling. In this case, you need > to be careful how you use address spaces. You're not really doing anything > wrong, clang was just never taught how to handle this case for NVPTX.Best regards, Nikolaos Kavvadias> >> Hi all, >> >> i'm trying to compile some small ANSI C benchmarks to PTX assembly. For >> this purpose, I'm using the NVPTX backend, introduced in the LLVM 3.2 >> release. >> >> It appears that certain LLVM constructs cannot be compiled to PTX. The >> problems mostly deal with handling of arrays. I also don't get any debug >> info when these problems. >> >> I use "llc" for compiling regular .ll files to PTX using the "nvptx" >> backend. The llc options are as follows (omitting these options also >> present the same problems): >> >> -nacdrvtest -asm-verbose -stats -print-before-all -print-after-all >> -time-passes >> >> 1. Only programs that make no use of arrays appear to always be processed >> correctly by llc (nvptx target). Some programs using arrays, make llc >> "hang" (runs endlessly). >> >> 2. One small C function exposing this behavior is as follows: >> >> // start here >> int arrtest (int x, int y) { >> unsigned char b[3]={0x10,0x30,0x55}; >> b[0] = (255 - b[x]) + b[y]; // doesn't work! >> // b[0] = (255 - b[0]) + b[1]; // works >> b[1] = x - y; >> b[2] = x * y; >> return b[0]; >> } >> // end here >> >> 3. A change that makes this function compilable (also visible in the >> comments) >> >> Change: >> b[0] = (255 - b[x]) + b[y]; >> to: >> b[0] = (255 - b[0]) + b[1]; >> >> Similarly, even the use of a single variable indexing (e.g. b[x]) doesn't >> work. >> >> Please note that if variable indexing is not used, then PTX assembly is >> generated. The problems seems related to the support/handling of variable >> indexing. >> >> However, the same code is always processed by other target backends (x86, >> mips). >> >> Is this behavior expected by the NVPTX backend? >> >> I understand that PTX is primarily targeted by OpenCL, however I would >> expect that the backend would issue some warnings on unimplemented features >> and not just run endlessly with no messages whatsoever. >> >> Best regards >> Nikolaos Kavvadias >> >> >> >> ______________________________**_________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu llvm.cs.uiuc.edu >> lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >> > > > > -- > > Thanks, > > Justin Holewinski >
Seemingly Similar Threads
- [LLVMdev] C-to-PTX compilation issues
- [LLVMdev] Problem with PTX assembly printing (NVPTX backend)
- [LLVMdev] Problem with PTX assembly printing (NVPTX backend)
- [LLVMdev] Problem with PTX assembly printing (NVPTX backend)
- [LLVMdev] Problem with PTX assembly printing (NVPTX backend)