[Openmp-commits] [PATCH] D62393: [OPENMP][NVPTX]Mark parallel level counter as volatile.

[Justin Lebar via Phabricator via Openmp-commits]

jlebar added a comment.

> So if we can drop cuda 8, great. If some of the maintainers have a customer that requires cuda 8 to continue working with a recent llvm - which is sad but plausible - we're better off supporting that use case in tree than forcing an out of tree fork.

This one revision, which attempts to work around one bug out of many in CUDA 8's ptxas, is months old and has about a hundred comments from many maintainers.  The cost of going down this road is huge and imposed on all backend maintainers.  You can see that here in this review, where tra got pulled in repeatedly, despite not having any direct interest in openmp.

As a primary maintainer of the NVPTX backend I would indeed prefer that someone fork LLVM than ask me for assistance supporting this old, buggy ptxas.

I have been down this road, it was my life for three years.  Ignore my cries at your own peril, etc etc.

> We don't need to cover many of the bugs to keep the deviceRTL working - it's 6k lines of relatively straightforward cuda that will exercise a small subset of the nvptx toolchain.

My objection isn't about deviceRTL specifically.

If those working on deviceRTL/openmp promise never to involve NVPTX backend maintainers in any discussions involving changes to deviceRTL/openmp source code to work around bugs in old ptxas, and promise never to suggest changes to clang or LLVM proper to work around such bugs, then you have my blessing to do whatever you'd like in your source code, just like any non-LLVM project which uses clang/llvm can make whatever changes to their code to work around whatever bugs.

In practice this would probably mean we'd need to set up email filters to send anything containing "openmp" to /dev/null.  But I think that's not the kind of community we want to build?  I want to partner with you all, and I think you all benefit from partnering with us.  Thus the need for whole-community standards as far as what we do and don't support.


Repository:
  rOMP OpenMP

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62393/new/

https://reviews.llvm.org/D62393