Hi LLVMers, We at NVIDIA would like to contribute back to the LLVM open-source community by up-streaming the NVPTX back-end for LLVM. This back-end is based on the sources used by NVIDIA, and currently provides significantly more functionality than the current PTX back-end. Some functionality is currently disabled due to dependencies on LLVM core changes that we are also in the process of up-streaming, but the back-end is very usable in its current state and would benefit all current and future users of the LLVM PTX back-end. The goal is to phase out the existing PTX back-end, while maintaining compatibility with it. To that end, the NVPTX back-end maintains its own set of intrinsics but also supports the old PTX back-end intrinsics to ensure compatibility with out-of-tree users. We would like to get your feedback on the attached patch to make sure it is up to LLVM commit quality. We would like to commit this as soon as the community is satisfied with it. Also, as the current maintainer of the PTX back-end, I give my consent to deprecate it. :) Thanks, Justin Holewinski ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120424/b623b53c/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: nvptx-backend-public.patch Type: application/octet-stream Size: 1045894 bytes Desc: nvptx-backend-public.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120424/b623b53c/attachment.obj>
On 4/24/2012 1:50 PM, Justin Holewinski wrote:> > Hi LLVMers, > > We at NVIDIA would like to contribute back to the LLVM open-source > community by up-streaming the NVPTX back-end for LLVM. This back-end > is based on the sources used by NVIDIA, and currently provides > significantly more functionality than the current PTX back-end. Some > functionality is currently disabled due to dependencies on LLVM core > changes that we are also in the process of up-streaming, but the > back-end is very usable in its current state and would benefit all > current and future users of the LLVM PTX back-end. >I've ended up having to make some local modifications to the PTX backend that I was preparing to post patches for, although, if it's going away, I guess I shouldn't bother. :-) Leafing through the patch briefly, though, I don't think I see any support for the LLVM rem instruction, nor do I see any support for the llvm exp2/log2 intrinsics... am I missing something, or are these operations (still) unsupported in the NVPTX backend? On the plus side, it's nice to see that at least two or three of the small fixes are already fixed. -- Joshua Cranmer News submodule owner DXR coauthor -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120424/d31f0d9e/attachment.html>
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Joshua Cranmer
Sent: Tuesday, April 24, 2012 9:54 PM
To: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] [PATCH][RFC] NVPTX Backend
On 4/24/2012 1:50 PM, Justin Holewinski wrote:
Hi LLVMers,
We at NVIDIA would like to contribute back to the LLVM open-source community by
up-streaming the NVPTX back-end for LLVM. This back-end is based on the sources
used by NVIDIA, and currently provides significantly more functionality than the
current PTX back-end. Some functionality is currently disabled due to
dependencies on LLVM core changes that we are also in the process of
up-streaming, but the back-end is very usable in its current state and would
benefit all current and future users of the LLVM PTX back-end.
I've ended up having to make some local modifications to the PTX backend
that I was preparing to post patches for, although, if it's going away, I
guess I shouldn't bother. :-)
If the patches are still applicable, then by all means! :)
Leafing through the patch briefly, though, I don't think I see any support
for the LLVM rem instruction, nor do I see any support for the llvm exp2/log2
intrinsics... am I missing something, or are these operations (still)
unsupported in the NVPTX backend? On the plus side, it's nice to see that at
least two or three of the small fixes are already fixed.
Integer srem/urem are supported (see NVPTXInstrInfo.td), frem is not. At the
moment, we only support intrinsics listed in the LLVM language reference, but
the PTX versions of ex2/lg2 are exposed through the
llvm.nvvm.{ex2,lg2}.approx.{f,d,ftz.f} intrinsics (see
include/llvm/IntrinsicsNVVM.td).
--
Joshua Cranmer
News submodule owner
DXR coauthor
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the sender
by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120425/62bc8050/attachment.html>
Hi Justin, Cool stuff, to be sure. Excited to see this. As a pre-cursor to more involved technical feedback, I suggest going through and fixing up the coding style and formatting issues. Just glancing through, I see lots of things like function names starting with capital letters, compound statements with the opening brace on the line following an if/for/while/etc., single-statements after an 'if' enclosed in a compound statement, container.end() being evaluated every iterations of loops, etc, etc.. -Jim On Apr 24, 2012, at 11:50 AM, Justin Holewinski <jholewinski at nvidia.com> wrote:> Hi LLVMers, > > We at NVIDIA would like to contribute back to the LLVM open-source community by up-streaming the NVPTX back-end for LLVM. This back-end is based on the sources used by NVIDIA, and currently provides significantly more functionality than the current PTX back-end. Some functionality is currently disabled due to dependencies on LLVM core changes that we are also in the process of up-streaming, but the back-end is very usable in its current state and would benefit all current and future users of the LLVM PTX back-end. > > The goal is to phase out the existing PTX back-end, while maintaining compatibility with it. To that end, the NVPTX back-end maintains its own set of intrinsics but also supports the old PTX back-end intrinsics to ensure compatibility with out-of-tree users. > > We would like to get your feedback on the attached patch to make sure it is up to LLVM commit quality. We would like to commit this as soon as the community is satisfied with it. > > Also, as the current maintainer of the PTX back-end, I give my consent to deprecate it. J > > > Thanks, > > Justin Holewinski > > This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. > > <nvptx-backend-public.patch>_______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120425/66473200/attachment.html>
Justin Holewinski
2012-Apr-27 19:50 UTC
[LLVMdev] [llvm-commits] [PATCH][RFC] NVPTX Backend
Thanks for the feedback! The attached patch addresses the style issues that have been found. From: Jim Grosbach [mailto:grosbach at apple.com] Sent: Wednesday, April 25, 2012 2:22 PM To: Justin Holewinski Cc: llvm-commits at cs.uiuc.edu; llvmdev at cs.uiuc.edu; Vinod Grover Subject: Re: [llvm-commits] [PATCH][RFC] NVPTX Backend Hi Justin, Cool stuff, to be sure. Excited to see this. As a pre-cursor to more involved technical feedback, I suggest going through and fixing up the coding style and formatting issues. Just glancing through, I see lots of things like function names starting with capital letters, compound statements with the opening brace on the line following an if/for/while/etc., single-statements after an 'if' enclosed in a compound statement, container.end() being evaluated every iterations of loops, etc, etc.. -Jim On Apr 24, 2012, at 11:50 AM, Justin Holewinski <jholewinski at nvidia.com<mailto:jholewinski at nvidia.com>> wrote: Hi LLVMers, We at NVIDIA would like to contribute back to the LLVM open-source community by up-streaming the NVPTX back-end for LLVM. This back-end is based on the sources used by NVIDIA, and currently provides significantly more functionality than the current PTX back-end. Some functionality is currently disabled due to dependencies on LLVM core changes that we are also in the process of up-streaming, but the back-end is very usable in its current state and would benefit all current and future users of the LLVM PTX back-end. The goal is to phase out the existing PTX back-end, while maintaining compatibility with it. To that end, the NVPTX back-end maintains its own set of intrinsics but also supports the old PTX back-end intrinsics to ensure compatibility with out-of-tree users. We would like to get your feedback on the attached patch to make sure it is up to LLVM commit quality. We would like to commit this as soon as the community is satisfied with it. Also, as the current maintainer of the PTX back-end, I give my consent to deprecate it. :) Thanks, Justin Holewinski ________________________________ This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ________________________________ <nvptx-backend-public.patch>_______________________________________________ llvm-commits mailing list llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120427/8f219f70/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: nvptx-backend-public.patch Type: application/octet-stream Size: 1026178 bytes Desc: nvptx-backend-public.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120427/8f219f70/attachment.obj>
Maybe Matching Threads
- [LLVMdev] [PATCH][RFC] NVPTX Backend
- [LLVMdev] [llvm-commits] [PATCH][RFC] NVPTX Backend
- [LLVMdev] [llvm-commits] [PATCH][RFC] NVPTX Backend
- [LLVMdev] [NVPTX] Eliminate common sub-expressions in a group of similar GEPs
- [LLVMdev] [NVPTX] Eliminate common sub-expressions in a group of similar GEPs