Hi, finally we changed the license of the PTX-backend from GPL to BSD(license of llvm). You can get the latest version here: https://sourceforge.net/projects/llvmptxbackend/ It should be compatible to the current llvm svn trunk. (revision 110329, Thu 05 Aug 2010) The backend now uses the address space attribute of LLVM for local, global, ... and constant address space. However the clang frontend handles address space attributes incorrectly. Thus writing the input code in C++ is some times cumbersome. We need to fix clang in this regard. Helge -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100806/57e32853/attachment.html>
On Aug 6, 2010, at 6:23 AM, Helge Rhodin wrote:> finally we changed the license of the PTX-backend from GPL to BSD(license of llvm). You can get the latest version here: https://sourceforge.net/projects/llvmptxbackend/ > It should be compatible to the current llvm svn trunk. (revision 110329, Thu 05 Aug 2010) > > The backend now uses the address space attribute of LLVM for local, global, ... and constant address space. However the clang frontend handles address space attributes incorrectly. Thus writing the input code in C++ is some times cumbersome. We need to fix clang in this regard. >Yes, we do! Please file bugs. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100806/119df7a6/attachment.html>
"Helge Rhodin" <helge.rhodin at alice-dsl.net> writes: Interesting! -Dave> Hi, > > finally we changed the license of the PTX-backend from GPL to BSD(license of llvm). You can get the latest version here: https:// > sourceforge.net/projects/llvmptxbackend/ > It should be compatible to the current llvm svn trunk. (revision 110329, Thu 05 Aug 2010) > > The backend now uses the address space attribute of LLVM for local, global, ... and constant address space. However the clang frontend > handles address space attributes incorrectly. Thus writing the input code in C++ is some times cumbersome. We need to fix clang in this > regard. > > Helge > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
"Helge Rhodin" <helge.rhodin at alice-dsl.net> writes:> Hi, > > finally we changed the license of the PTX-backend from GPL to BSD(license of llvm). You can get the latest version here: https:// > sourceforge.net/projects/llvmptxbackend/ > It should be compatible to the current llvm svn trunk. (revision 110329, Thu 05 Aug 2010)Is there work to upstream this? I've got a relatively unused NVIDIA card at home. :) -Dave
Alexander Herz
2010-Oct-18 15:31 UTC
[LLVMdev] pass case sensitive information to a llvm target backend
Hi, we're writing a new target backend (based on the c backend) for the llvm. We need to pass case sensitive strings from the command line to the backend (unix paths). Currently we're using the Subtarget features string to relay the information. It turns out that the llvm applies a to_lower to the this string, so unix paths become basically useless. Is there a better way to pass this information to the backend. If not, what are the chances that a patch that disables the conversion to lower case for this string is accepted? Thx, Alex P.S.: Sorry for double post, this belongs on llvmdev not cfe-dev
Jim Grosbach
2010-Oct-18 17:13 UTC
[LLVMdev] pass case sensitive information to a llvm target backend
On Oct 18, 2010, at 8:31 AM, Alexander Herz wrote:> we're writing a new target backend (based on the c backend) for the > llvm. We need to pass case sensitive strings from the command line to > the backend (unix paths). Currently we're using the Subtarget features > string to relay the information. > It turns out that the llvm applies a to_lower to the this string, so > unix paths become basically useless. > Is there a better way to pass this information to the backend. If not, > what are the chances that a patch that disables the conversion to lower > case for this string is accepted?Hi Alex, Whether there's a better way to pass the information you want to the backend will likely depend a bit more on the specifics of what you're trying to do. Can you elaborate a bit with a simple example, perhaps? -Jim