* [wwwdocs][patch] gcc-12/changes.html: Document -misa update for nvptx @ 2022-03-03 12:27 Tobias Burnus 2022-03-30 12:27 ` [wwwdocs][patch] gcc-12: Nvptx updates Tom de Vries 0 siblings, 1 reply; 9+ messages in thread From: Tobias Burnus @ 2022-03-03 12:27 UTC (permalink / raw) To: Tom de Vries, gcc-patches [-- Attachment #1: Type: text/plain, Size: 437 bytes --] The current wording, https://gcc.gnu.org/gcc-12/changes.html#nvptx , is outdated and (now wrongly) encourages to use -mptx=. Updated as follows. OK? Tobias ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 [-- Attachment #2: wwwdocs.diff --] [-- Type: text/x-patch, Size: 1122 bytes --] gcc-12/changes.html: Document -misa update for nvptx diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html index a3e46eeb..63e2bf63 100644 --- a/htdocs/gcc-12/changes.html +++ b/htdocs/gcc-12/changes.html @@ -468,9 +468,14 @@ a work-in-progress.</p> <h3 id="nvptx">NVPTX</h3> <ul> + <li>The <code>-misa/<code> flag now supports <code>sm_53</code>, + <code>sm_70</code>, <code>sm_75</code>, and <code>sm_80</code> besides + <code>sm_30</code> and <code>sm_35</code> (which is the default).</li> <li>The <code>-mptx</code> flag has been added to specify the PTX ISA version for the generated code; permitted values are <code>3.1</code> - (default, matches previous GCC versions) and <code>6.3</code>. + (matches previous GCC versions), <code>6.0</code>, <code>6.3</code>, + and <code>7.0</code>. If not specified, the used version is the minimal + version required for <code>-misa</code> but at least <code>6.0</code>. </li> <li>The new <code>__PTX_SM__</code> predefined macro allows code to check the compute model being targeted by the compiler.</li> ^ permalink raw reply [flat|nested] 9+ messages in thread
* [wwwdocs][patch] gcc-12: Nvptx updates. 2022-03-03 12:27 [wwwdocs][patch] gcc-12/changes.html: Document -misa update for nvptx Tobias Burnus @ 2022-03-30 12:27 ` Tom de Vries 2022-04-05 15:14 ` Proposal to remove '--with-cuda-driver' (was: [wwwdocs][patch] gcc-12: Nvptx updates) Thomas Schwinge 0 siblings, 1 reply; 9+ messages in thread From: Tom de Vries @ 2022-03-30 12:27 UTC (permalink / raw) To: Tobias Burnus, gcc-patches; +Cc: Thomas Schwinge, Roger Sayle [-- Attachment #1: Type: text/plain, Size: 2058 bytes --] [ was: Re: [wwwdocs][patch] gcc-12/changes.html: Document -misa update for nvptx ] On 3/3/22 13:27, Tobias Burnus wrote: > The current wording, https://gcc.gnu.org/gcc-12/changes.html#nvptx , > is outdated and (now wrongly) encourages to use -mptx=. > > Updated as follows. I've taken these changes as a base, revised and added some more items. Any comments? Also, feel free to instead comment on the full-text version below (copied from firefox after opening the page), that might be more readable. Thanks, - Tom ----------------------------------------------------------------------------- NVPTX The -march flag has been added. The -misa flag is now considered an alias of the -march flag. Support for PTX ISA target architectures sm_53, sm_70, sm_75 and sm_80 has been added. These can be specified using the -march flag. The default PTX ISA target architecture has been set back to sm_30, to fix support for sm_30 boards. The -march-map flag has been added. The -march-map value will be mapped to an valid -march flag value. For instance, -march-map=sm_50 maps to -march=sm_35. This can be used to specify that generated code is to be executed on a board with at least some specific compute capability, without having to know the valid values for the -march flag. The -mptx flag has been added to specify the PTX ISA version for the generated code; permitted values are 3.1 (matches previous GCC versions), 6.0, 6.3, and 7.0. If not specified, the used version is the minimal version required for -march but at least 6.0. An mptx-3.1 multilib was added. This allows using older drivers which do not support PTX ISA version 6.0. The new __PTX_SM__ predefined macro allows code to check the PTX ISA target architecture being targeted by the compiler. The new __PTX_ISA_VERSION_MAJOR__ and __PTX_ISA_VERSION_MINOR__ predefined macros allows code to check the PTX ISA version being targeted by the compiler. ----------------------------------------------------------------------------- [-- Attachment #2: 0001-gcc-12-Nvptx-updates.patch --] [-- Type: text/x-patch, Size: 2489 bytes --] gcc-12: Nvptx updates. Co-Authored-By: Tobias Burnus <tobias@codesourcery.com> --- htdocs/gcc-12/changes.html | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html index 689feeba..d95f7253 100644 --- a/htdocs/gcc-12/changes.html +++ b/htdocs/gcc-12/changes.html @@ -493,12 +493,33 @@ a work-in-progress.</p> <h3 id="nvptx">NVPTX</h3> <ul> + <li>The <code>-march</code> flag has been added. The <code>-misa</code> + flag is now considered an alias of the <code>-march</code> flag.</li> + <li>Support for PTX ISA target architectures <code>sm_53</code>, + <code>sm_70</code>, <code>sm_75</code> and <code>sm_80</code> has been + added. These can be specified using the <code>-march</code> flag.</li> + <li>The default PTX ISA target architecture has been set back + to <code>sm_30</code>, to fix support for <code>sm_30</code> boards.</li> + <li>The <code>-march-map</code> flag has been added. The + <code>-march-map</code> value will be mapped to an valid + <code>-march</code> flag value. For instance, + <code>-march-map=sm_50</code> maps to <code>-march=sm_35</code>. + This can be used to specify that generated code is to be executed on a + board with at least some specific compute capability, without having to + know the valid values for the <code>-march</code> flag.</li> <li>The <code>-mptx</code> flag has been added to specify the PTX ISA version for the generated code; permitted values are <code>3.1</code> - (default, matches previous GCC versions) and <code>6.3</code>. + (matches previous GCC versions), <code>6.0</code>, <code>6.3</code>, + and <code>7.0</code>. If not specified, the used version is the minimal + version required for <code>-march</code> but at least <code>6.0</code>. </li> + <li>An <code>mptx-3.1</code> multilib was added. This allows using older + drivers which do not support PTX ISA version 6.0.</li> <li>The new <code>__PTX_SM__</code> predefined macro allows code to check the - compute model being targeted by the compiler.</li> + PTX ISA target architecture being targeted by the compiler.</li> + <li>The new <code>__PTX_ISA_VERSION_MAJOR__</code> + and <code>__PTX_ISA_VERSION_MINOR__</code> predefined macros allows code + to check the PTX ISA version being targeted by the compiler.</li> </ul> <!-- <h3 id="hppa">PA-RISC</h3> --> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Proposal to remove '--with-cuda-driver' (was: [wwwdocs][patch] gcc-12: Nvptx updates) 2022-03-30 12:27 ` [wwwdocs][patch] gcc-12: Nvptx updates Tom de Vries @ 2022-04-05 15:14 ` Thomas Schwinge 2022-04-05 18:46 ` Roger Sayle 2022-04-06 9:57 ` Proposal to remove '--with-cuda-driver' (was: [wwwdocs][patch] gcc-12: Nvptx updates) Tom de Vries 0 siblings, 2 replies; 9+ messages in thread From: Thomas Schwinge @ 2022-04-05 15:14 UTC (permalink / raw) To: Tom de Vries, Jakub Jelinek; +Cc: gcc-patches, Tobias Burnus, Roger Sayle Hi! Still catching up with GCC/nvptx back end changes... %-) In the following I'm not discussing the patch to document "gcc-12: Nvptx updates", but rather one aspect of the "gcc-12: Nvptx updates" themselves. ;-) On 2022-03-30T14:27:41+0200, Tom de Vries <tdevries@suse.de> wrote: > + <li>The <code>-march</code> flag has been added. The <code>-misa</code> > + flag is now considered an alias of the <code>-march</code> flag.</li> > + <li>Support for PTX ISA target architectures <code>sm_53</code>, > + <code>sm_70</code>, <code>sm_75</code> and <code>sm_80</code> has been > + added. These can be specified using the <code>-march</code> flag.</li> > + <li>The default PTX ISA target architecture has been set back > + to <code>sm_30</code>, to fix support for <code>sm_30</code> boards.</li> > + <li>The <code>-march-map</code> flag has been added. The > + <code>-march-map</code> value will be mapped to an valid > + <code>-march</code> flag value. For instance, > + <code>-march-map=sm_50</code> maps to <code>-march=sm_35</code>. > + This can be used to specify that generated code is to be executed on a > + board with at least some specific compute capability, without having to > + know the valid values for the <code>-march</code> flag.</li> Regarding the following: > <li>The <code>-mptx</code> flag has been added to specify the PTX ISA version > for the generated code; permitted values are <code>3.1</code> > - (default, matches previous GCC versions) and <code>6.3</code>. > + (matches previous GCC versions), <code>6.0</code>, <code>6.3</code>, > + and <code>7.0</code>. If not specified, the used version is the minimal > + version required for <code>-march</code> but at least <code>6.0</code>. > </li> For "the PTX ISA version [used is] at least '6.0'", per <https://docs.nvidia.com/cuda/parallel-thread-execution/#release-notes>, this means we now require "CUDA 9.0, driver r384" (or more recent). Per <https://developer.nvidia.com/cuda-toolkit-archive>: "CUDA Toolkit 9.0 (Sept 2017)", so ~4.5 years old. Per <https://download.nvidia.com/XFree86/Linux-x86_64/>, I'm guessing a similar timeframe for the imprecise "r384" Driver version stated in that table. That should all be fine (re not mandating use of all-too-recent versions). Now, consider doing a GCC/nvptx offloading build with '--with-cuda-driver' pointing to CUDA 9.0 (or more recent). This means that the libgomp nvptx plugin may now use CUDA Driver features of the CUDA 9.0 distribution ("driver r384", etc.) -- because that's what it is being 'configure'd and linked against. (I say "may now use", because we're currently not making a lot of effort to use "modern" CUDA Driver features -- but we could, and probably should. That's a separate discussion, of course.) It then follows that the libgomp nvptx plugin has a hard dependency on CUDA Driver features of the CUDA 9.0 distribution ("driver r384", etc.). That's dependency as in ABI: via '*.so' symbol versions as well as internal CUDA interface configuration; see <cuda.h> doing different '#define's for different '__CUDA_API_VERSION' etc.) Now assume one such dependency on "modern" CUDA Driver were not implemented by: > + <li>An <code>mptx-3.1</code> multilib was added. This allows using older > + drivers which do not support PTX ISA version 6.0.</li> ... this "old" CUDA Driver. Then you do have the '-mptx-3.1' multilib to use with "old" CUDA Driver -- but you cannot actually use the libgomp nvptx plugin, because that's been built against "modern" CUDA Driver. Same problem, generally, for 'nvptx-run' of the nvptx-tools, which has similar CUDA Driver dependencies. Now, that may currently be a latent problem only, because we're not actually making use of "modern" CUDA Driver features. But, I'd like to resolve this "impedance mismatch", before we actually run into such problems. Already long ago Jakub put in changes to use '--without-cuda-driver' to "Allow building GCC with PTX offloading even without CUDA being installed (gcc and nvptx-tools patches)": "Especially for distributions it is undesirable to need to have proprietary CUDA libraries and headers installed when building GCC.", and I understand GNU/Linux distributions all use that. That configuration uses the GCC-provided 'libgomp/plugin/cuda/cuda.h', 'libgomp/plugin/cuda-lib.def' to manually define the CUDA Driver ABI to use, and then 'dlopen("libcuda.so.1")'. (Similar to what the libgomp GCN (and before: HSA) plugin is doing, for example.) Quite likely that our group (at work) are the only ones to actually use '--with-cuda-driver'? My proposal now is: we remove '--with-cuda-driver' (make its use a no-op, per standard GNU Autoconf behavior), and offer '--without-cuda-driver' only. This shouldn't cause any user-visible change in behavior, so safe without a prior deprecation phase. Before I prepare the patches (GCC, nvptx-tools): any comments or objections? Grüße Thomas > <li>The new <code>__PTX_SM__</code> predefined macro allows code to check the > - compute model being targeted by the compiler.</li> > + PTX ISA target architecture being targeted by the compiler.</li> > + <li>The new <code>__PTX_ISA_VERSION_MAJOR__</code> > + and <code>__PTX_ISA_VERSION_MINOR__</code> predefined macros allows code > + to check the PTX ISA version being targeted by the compiler.</li> > </ul> ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Proposal to remove '--with-cuda-driver' (was: [wwwdocs][patch] gcc-12: Nvptx updates) 2022-04-05 15:14 ` Proposal to remove '--with-cuda-driver' (was: [wwwdocs][patch] gcc-12: Nvptx updates) Thomas Schwinge @ 2022-04-05 18:46 ` Roger Sayle 2022-04-29 13:55 ` Proposal to remove '--with-cuda-driver' Thomas Schwinge 2022-04-06 9:57 ` Proposal to remove '--with-cuda-driver' (was: [wwwdocs][patch] gcc-12: Nvptx updates) Tom de Vries 1 sibling, 1 reply; 9+ messages in thread From: Roger Sayle @ 2022-04-05 18:46 UTC (permalink / raw) To: 'Thomas Schwinge', 'Tom de Vries', 'Jakub Jelinek' Cc: gcc-patches, 'Tobias Burnus' Hi Thomas, I apologise that it might complicate things, but one potential benefit of --with-cuda-driver (i.e. linking the compiler against proprietary libraries) is that it would allow support for -march=native on nvptx (i.e. the gcc driver can figure out what sm_xx is available on the GPU(s) of the current machine, and pass that to cc1. Like with all the microarchitectures on other platforms (x86_64), figuring this out is not a trivial task for many end-users. Of course, ideally I'd love to be able to figure out the PTX hardware specifications and driver versions without using a third-party library, but I've no idea how this could be done (portably across the platforms that support libcuda). Perhaps dlopen at runtime? Or calling out to (executing) nvptx-tools? Cheers, Roger -- > -----Original Message----- > From: Thomas Schwinge <thomas@codesourcery.com> > Sent: 05 April 2022 16:14 > To: Tom de Vries <tdevries@suse.de>; Jakub Jelinek <jakub@redhat.com> > Cc: gcc-patches@gcc.gnu.org; Tobias Burnus <tobias@codesourcery.com>; > Roger Sayle <roger@nextmovesoftware.com> > Subject: Proposal to remove '--with-cuda-driver' (was: [wwwdocs][patch] gcc- > 12: Nvptx updates) > > Hi! > > Still catching up with GCC/nvptx back end changes... %-) > > > In the following I'm not discussing the patch to document > "gcc-12: Nvptx updates", but rather one aspect of the > "gcc-12: Nvptx updates" themselves. ;-) > > On 2022-03-30T14:27:41+0200, Tom de Vries <tdevries@suse.de> wrote: > > + <li>The <code>-march</code> flag has been added. The <code>- > misa</code> > > + flag is now considered an alias of the <code>-march</code> > > + flag.</li> <li>Support for PTX ISA target architectures <code>sm_53</code>, > > + <code>sm_70</code>, <code>sm_75</code> and <code>sm_80</code> > has been > > + added. These can be specified using the <code>-march</code> > > + flag.</li> <li>The default PTX ISA target architecture has been set back > > + to <code>sm_30</code>, to fix support for <code>sm_30</code> > > + boards.</li> <li>The <code>-march-map</code> flag has been added. The > > + <code>-march-map</code> value will be mapped to an valid > > + <code>-march</code> flag value. For instance, > > + <code>-march-map=sm_50</code> maps to <code>- > march=sm_35</code>. > > + This can be used to specify that generated code is to be executed on a > > + board with at least some specific compute capability, without having to > > + know the valid values for the <code>-march</code> flag.</li> > > Regarding the following: > > > <li>The <code>-mptx</code> flag has been added to specify the PTX ISA > version > > for the generated code; permitted values are <code>3.1</code> > > - (default, matches previous GCC versions) and <code>6.3</code>. > > + (matches previous GCC versions), <code>6.0</code>, <code>6.3</code>, > > + and <code>7.0</code>. If not specified, the used version is the minimal > > + version required for <code>-march</code> but at least > <code>6.0</code>. > > </li> > > For "the PTX ISA version [used is] at least '6.0'", per > <https://docs.nvidia.com/cuda/parallel-thread-execution/#release-notes>, > this means we now require "CUDA 9.0, driver r384" (or more recent). > Per <https://developer.nvidia.com/cuda-toolkit-archive>: > "CUDA Toolkit 9.0 (Sept 2017)", so ~4.5 years old. > Per <https://download.nvidia.com/XFree86/Linux-x86_64/>, I'm guessing a > similar timeframe for the imprecise "r384" Driver version stated in that table. > That should all be fine (re not mandating use of all-too-recent versions). > > Now, consider doing a GCC/nvptx offloading build with '--with-cuda-driver' > pointing to CUDA 9.0 (or more recent). This means that the libgomp nvptx > plugin may now use CUDA Driver features of the CUDA 9.0 distribution ("driver > r384", etc.) -- because that's what it is being 'configure'd and linked against. (I > say "may now use", because we're currently not making a lot of effort to use > "modern" CUDA Driver features -- but we could, and probably should. That's a > separate discussion, of course.) It then follows that the libgomp nvptx plugin > has a hard dependency on CUDA Driver features of the CUDA 9.0 distribution > ("driver r384", etc.). That's dependency as in ABI: via '*.so' symbol versions as > well as internal CUDA interface configuration; see <cuda.h> doing different > '#define's for different '__CUDA_API_VERSION' etc.) > > Now assume one such dependency on "modern" CUDA Driver were not > implemented by: > > > + <li>An <code>mptx-3.1</code> multilib was added. This allows using older > > + drivers which do not support PTX ISA version 6.0.</li> > > ... this "old" CUDA Driver. Then you do have the '-mptx-3.1' multilib to use with > "old" CUDA Driver -- but you cannot actually use the libgomp nvptx plugin, > because that's been built against "modern" CUDA Driver. > > Same problem, generally, for 'nvptx-run' of the nvptx-tools, which has similar > CUDA Driver dependencies. > > Now, that may currently be a latent problem only, because we're not actually > making use of "modern" CUDA Driver features. But, I'd like to resolve this > "impedance mismatch", before we actually run into such problems. > > Already long ago Jakub put in changes to use '--without-cuda-driver' to "Allow > building GCC with PTX offloading even without CUDA being installed (gcc and > nvptx-tools patches)": "Especially for distributions it is undesirable to need to > have proprietary CUDA libraries and headers installed when building GCC.", and I > understand GNU/Linux distributions all use that. That configuration uses the > GCC-provided 'libgomp/plugin/cuda/cuda.h', 'libgomp/plugin/cuda-lib.def' to > manually define the CUDA Driver ABI to use, and then 'dlopen("libcuda.so.1")'. > (Similar to what the libgomp GCN (and before: HSA) plugin is doing, for > example.) Quite likely that our group (at work) are the only ones to actually use > '--with-cuda-driver'? > > My proposal now is: we remove '--with-cuda-driver' (make its use a no-op, per > standard GNU Autoconf behavior), and offer '--without-cuda-driver' > only. This shouldn't cause any user-visible change in behavior, so safe without a > prior deprecation phase. > > Before I prepare the patches (GCC, nvptx-tools): any comments or objections? > > > Grüße > Thomas > > > > <li>The new <code>__PTX_SM__</code> predefined macro allows code to > check the > > - compute model being targeted by the compiler.</li> > > + PTX ISA target architecture being targeted by the > > + compiler.</li> <li>The new <code>__PTX_ISA_VERSION_MAJOR__</code> > > + and <code>__PTX_ISA_VERSION_MINOR__</code> predefined macros > allows code > > + to check the PTX ISA version being targeted by the > > + compiler.</li> > > </ul> > ----------------- > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, > 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: > Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht > München, HRB 106955 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Proposal to remove '--with-cuda-driver' 2022-04-05 18:46 ` Roger Sayle @ 2022-04-29 13:55 ` Thomas Schwinge 0 siblings, 0 replies; 9+ messages in thread From: Thomas Schwinge @ 2022-04-29 13:55 UTC (permalink / raw) To: Roger Sayle Cc: 'Tom de Vries', 'Jakub Jelinek', gcc-patches, 'Tobias Burnus' Hi Roger! On 2022-04-05T19:46:08+0100, "Roger Sayle" <roger@nextmovesoftware.com> wrote: > I apologise that it might complicate things No worries; that's why I asked. :-) > one potential benefit of --with-cuda-driver > (i.e. linking the compiler against proprietary libraries) is that it would allow support for > -march=native on nvptx (i.e. the gcc driver can figure out what sm_xx is available on the > GPU(s) of the current machine, and pass that to cc1. Like with all the microarchitectures > on other platforms (x86_64), figuring this out is not a trivial task for many end-users. Ah, interesting idea! (I suppose still not too relevant right now, but once we've got GCC/nvptx multilibs making better use of modern PTX features, I certainly do see the point.) > Of course, ideally I'd love to be able to figure out the PTX hardware specifications and > driver versions without using a third-party library, but I've no idea how this could be done > (portably across the platforms that support libcuda). Perhaps dlopen at runtime? > Or calling out to (executing) nvptx-tools? Indeed I suppose I'd do this via 'dlopen', and not directly link GCC against 'libcuda.so' etc.: so that the GCC build may also be used on a system where no 'libcuda.so' is available. So -- sorry ;-) -- that's not a show-stopper for removing the '--with-cuda-driver' etc. 'configure'-time options. Grüße Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Proposal to remove '--with-cuda-driver' (was: [wwwdocs][patch] gcc-12: Nvptx updates) 2022-04-05 15:14 ` Proposal to remove '--with-cuda-driver' (was: [wwwdocs][patch] gcc-12: Nvptx updates) Thomas Schwinge 2022-04-05 18:46 ` Roger Sayle @ 2022-04-06 9:57 ` Tom de Vries 2022-04-29 13:48 ` Proposal to remove '--with-cuda-driver' Thomas Schwinge 1 sibling, 1 reply; 9+ messages in thread From: Tom de Vries @ 2022-04-06 9:57 UTC (permalink / raw) To: Thomas Schwinge, Jakub Jelinek; +Cc: gcc-patches, Tobias Burnus, Roger Sayle On 4/5/22 17:14, Thomas Schwinge wrote: > Hi! > > Still catching up with GCC/nvptx back end changes... %-) > > > In the following I'm not discussing the patch to document > "gcc-12: Nvptx updates", but rather one aspect of the > "gcc-12: Nvptx updates" themselves. ;-) > > On 2022-03-30T14:27:41+0200, Tom de Vries <tdevries@suse.de> wrote: >> + <li>The <code>-march</code> flag has been added. The <code>-misa</code> >> + flag is now considered an alias of the <code>-march</code> flag.</li> >> + <li>Support for PTX ISA target architectures <code>sm_53</code>, >> + <code>sm_70</code>, <code>sm_75</code> and <code>sm_80</code> has been >> + added. These can be specified using the <code>-march</code> flag.</li> >> + <li>The default PTX ISA target architecture has been set back >> + to <code>sm_30</code>, to fix support for <code>sm_30</code> boards.</li> >> + <li>The <code>-march-map</code> flag has been added. The >> + <code>-march-map</code> value will be mapped to an valid >> + <code>-march</code> flag value. For instance, >> + <code>-march-map=sm_50</code> maps to <code>-march=sm_35</code>. >> + This can be used to specify that generated code is to be executed on a >> + board with at least some specific compute capability, without having to >> + know the valid values for the <code>-march</code> flag.</li> > > Regarding the following: > >> <li>The <code>-mptx</code> flag has been added to specify the PTX ISA version >> for the generated code; permitted values are <code>3.1</code> >> - (default, matches previous GCC versions) and <code>6.3</code>. >> + (matches previous GCC versions), <code>6.0</code>, <code>6.3</code>, >> + and <code>7.0</code>. If not specified, the used version is the minimal >> + version required for <code>-march</code> but at least <code>6.0</code>. >> </li> > > For "the PTX ISA version [used is] at least '6.0'", per > <https://docs.nvidia.com/cuda/parallel-thread-execution/#release-notes>, > this means we now require "CUDA 9.0, driver r384" (or more recent). Well, that would be the case if there was no -mptx=3.1. > Per <https://developer.nvidia.com/cuda-toolkit-archive>: > "CUDA Toolkit 9.0 (Sept 2017)", so ~4.5 years old. > Per <https://download.nvidia.com/XFree86/Linux-x86_64/>, I'm guessing a I just see a list with version numbers there, I'm not sure what information you're referring to. > similar timeframe for the imprecise "r384" Driver version stated in that > table. That should all be fine (re not mandating use of all-too-recent > versions). > I don't know what an imprecise driver is. > Now, consider doing a GCC/nvptx offloading build with > '--with-cuda-driver' pointing to CUDA 9.0 (or more recent). This means > that the libgomp nvptx plugin may now use CUDA Driver features of the > CUDA 9.0 distribution ("driver r384", etc.) -- because that's what it is > being 'configure'd and linked against. (I say "may now use", because > we're currently not making a lot of effort to use "modern" CUDA Driver > features -- but we could, and probably should. That's a separate > discussion, of course.) It then follows that the libgomp nvptx plugin > has a hard dependency on CUDA Driver features of the CUDA 9.0 > distribution ("driver r384", etc.). That's dependency as in ABI: via > '*.so' symbol versions as well as internal CUDA interface configuration; > see <cuda.h> doing different '#define's for different > '__CUDA_API_VERSION' etc.) > > Now assume one such dependency on "modern" CUDA Driver were not > implemented by: > Thanks for reminding me, I forgot about this configure option. >> + <li>An <code>mptx-3.1</code> multilib was added. This allows using older >> + drivers which do not support PTX ISA version 6.0.</li> > > ... this "old" CUDA Driver. Then you do have the '-mptx-3.1' multilib to > use with "old" CUDA Driver -- but you cannot actually use the libgomp > nvptx plugin, because that's been built against "modern" CUDA Driver. > I remember the following problem: using -with-cuda-driver to specify what cuda driver interface (version) you want to link the libgomp plugin against, and then using an older driver in combination with that libgomp plugin. We may run into trouble, typically at libgomp plugin load time, with an error mentioning an unresolved symbol or some abi symbol version being not sufficient. So, do I understand it correctly that your point is that using -mptx=3.1 doesn't fix that problem? > Same problem, generally, for 'nvptx-run' of the nvptx-tools, which has > similar CUDA Driver dependencies. > > Now, that may currently be a latent problem only, because we're not > actually making use of "modern" CUDA Driver features. But, I'd like to > resolve this "impedance mismatch", before we actually run into such > problems. > It would be helpful for me if you would come up with an example of a modification to the libgomp plugin that would cause trouble in combination with mptx=3.1. > Already long ago Jakub put in changes to use '--without-cuda-driver' to > "Allow building GCC with PTX offloading even without CUDA being installed > (gcc and nvptx-tools patches)": "Especially for distributions it is > undesirable to need to have proprietary CUDA libraries and headers > installed when building GCC.", and I understand GNU/Linux distributions > all use that. That configuration uses the GCC-provided > 'libgomp/plugin/cuda/cuda.h', 'libgomp/plugin/cuda-lib.def' to manually > define the CUDA Driver ABI to use, and then 'dlopen("libcuda.so.1")'. > (Similar to what the libgomp GCN (and before: HSA) plugin is doing, for > example.) Quite likely that our group (at work) are the only ones to > actually use '--with-cuda-driver'? > Right, I see in my scripts that I don't use --with-cuda-driver, possibly because of years-ago running into issues when changing drivers forth and back. > My proposal now is: we remove '--with-cuda-driver' (make its use a no-op, > per standard GNU Autoconf behavior), and offer '--without-cuda-driver' > only. This shouldn't cause any user-visible change in behavior, so safe > without a prior deprecation phase. > I think the dlopen use-case is the most flexible, and I don't see any user benefit from using --with-cuda-driver, so I don't see a problem with removing --with-cuda-driver for the user. I did wonder about keeping it available in some form, say rename to --maintainer-mode-with-cuda-driver. This could be useful for debugging / comparison purposes. But it would mean having to test it when making relevant changes, which is maintenance burden for a feature not visible to the user, so I guess that's not worth it. So, I'm fine with removing. Thanks, - Tom ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Proposal to remove '--with-cuda-driver' 2022-04-06 9:57 ` Proposal to remove '--with-cuda-driver' (was: [wwwdocs][patch] gcc-12: Nvptx updates) Tom de Vries @ 2022-04-29 13:48 ` Thomas Schwinge 2022-05-13 12:29 ` libgomp nvptx plugin: Remove '--with-cuda-driver=[...]' etc. configuration option (was: Proposal to remove '--with-cuda-driver') Thomas Schwinge 0 siblings, 1 reply; 9+ messages in thread From: Thomas Schwinge @ 2022-04-29 13:48 UTC (permalink / raw) To: Tom de Vries; +Cc: Jakub Jelinek, gcc-patches, Tobias Burnus, Roger Sayle Hi Tom! On 2022-04-06T11:57:57+0200, Tom de Vries <tdevries@suse.de> wrote: > On 4/5/22 17:14, Thomas Schwinge wrote: >> Regarding the following: >> >> On 2022-03-30T14:27:41+0200, Tom de Vries <tdevries@suse.de> wrote: >>> <li>The <code>-mptx</code> flag has been added to specify the PTX ISA version >>> for the generated code; permitted values are <code>3.1</code> >>> - (default, matches previous GCC versions) and <code>6.3</code>. >>> + (matches previous GCC versions), <code>6.0</code>, <code>6.3</code>, >>> + and <code>7.0</code>. If not specified, the used version is the minimal >>> + version required for <code>-march</code> but at least <code>6.0</code>. >>> </li> >> >> For "the PTX ISA version [used is] at least '6.0'", per >> <https://docs.nvidia.com/cuda/parallel-thread-execution/#release-notes>, >> this means we now require "CUDA 9.0, driver r384" (or more recent). > > Well, that would be the case if there was no -mptx=3.1. When considering *using* GCC/nvptx, the '-mptx-3.1' multilib may be used with "old" hardware/CUDA Driver versions, correct. When considering *building* GCC/nvptx, we do require CUDA 9.0, as otherwise the default multilib can't be built (unless you disable 'ptxas' verification). >> Per <https://developer.nvidia.com/cuda-toolkit-archive>: >> "CUDA Toolkit 9.0 (Sept 2017)", so ~4.5 years old. >> Per <https://download.nvidia.com/XFree86/Linux-x86_64/>, I'm guessing a > > I just see a list with version numbers there, I'm not sure what > information you're referring to. I'd assumed that from that URL as well as structure of these version numbers, you could tell these are Nvidia Driver releases (including bundled CUDA Driver libraries). >> similar timeframe for the imprecise "r384" Driver version stated in that >> table. That should all be fine (re not mandating use of all-too-recent >> versions). > > I don't know what an imprecise driver is. Not "imprecise driver" but "imprecise [...] version". For example, <https://docs.nvidia.com/cuda/parallel-thread-execution/#release-notes> talks about "driver r384", but such a version doesn't exist; it's rather 384.130, or 384.111, or 384.98, etc. >> Now, consider doing a GCC/nvptx offloading build with >> '--with-cuda-driver' pointing to CUDA 9.0 (or more recent). This means >> that the libgomp nvptx plugin may now use CUDA Driver features of the >> CUDA 9.0 distribution ("driver r384", etc.) -- because that's what it is >> being 'configure'd and linked against. (I say "may now use", because >> we're currently not making a lot of effort to use "modern" CUDA Driver >> features -- but we could, and probably should. That's a separate >> discussion, of course.) It then follows that the libgomp nvptx plugin >> has a hard dependency on CUDA Driver features of the CUDA 9.0 >> distribution ("driver r384", etc.). That's dependency as in ABI: via >> '*.so' symbol versions as well as internal CUDA interface configuration; >> see <cuda.h> doing different '#define's for different >> '__CUDA_API_VERSION' etc.) >> >> Now assume one such dependency on "modern" CUDA Driver were not >> implemented by: > > Thanks for reminding me, I forgot about this configure option. OK, good. ;-) >>> + <li>An <code>mptx-3.1</code> multilib was added. This allows using older >>> + drivers which do not support PTX ISA version 6.0.</li> >> >> ... this "old" CUDA Driver. Then you do have the '-mptx-3.1' multilib to >> use with "old" CUDA Driver -- but you cannot actually use the libgomp >> nvptx plugin, because that's been built against "modern" CUDA Driver. > > I remember the following problem: using -with-cuda-driver to specify > what cuda driver interface (version) you want to link the libgomp plugin > against, and then using an older driver in combination with that libgomp > plugin. We may run into trouble, typically at libgomp plugin load > time, with an error mentioning an unresolved symbol or some abi symbol > version being not sufficient. Right. > So, do I understand it correctly that your point is that using -mptx=3.1 > doesn't fix that problem? Right. >> Same problem, generally, for 'nvptx-run' of the nvptx-tools, which has >> similar CUDA Driver dependencies. >> >> Now, that may currently be a latent problem only, because we're not >> actually making use of "modern" CUDA Driver features. But, I'd like to >> resolve this "impedance mismatch", before we actually run into such >> problems. > > It would be helpful for me if you would come up with an example of a > modification to the libgomp plugin that would cause trouble in > combination with mptx=3.1. For example, something like the following scenario -- made up, so details may be wrong. Consider GCC's libgomp nvptx plugin is built with '--with-cuda-driver' pointing to a modern CUDA release. The 'configure' script finds the 'cuMemPrefetchAsync' function available (CUDA 8.0+?), enables respective hypothetical code in the libgomp nvptx plugin, and thus 'libgomp-plugin-nvptx.so' now has a load-time dependency on 'libcuda.so' providing 'cuMemPrefetchAsync': the plugin will fail to load if that's not available. If you now use this plugin on an "old" system (old CUDA Driver version), the '-mptx-3.1' multilib that is meant to keep tings working for such "old" configurations, doesn't help, because the plugin won't load. (Orthogonal aspects.) ..., and I've since discovered that we use 'libgomp/plugin/cuda-lib.def' not just for 'PLUGIN_NVPTX_DYNAMIC' (that is, '--without-cuda-driver') configurations, but also for '!PLUGIN_NVPTX_DYNAMIC' (that is, '--with-cuda-driver') configurations. So, instead of 'configure'-time detection of 'cuMemPrefetchAsync' availability and using 'CUDA_CALL (cuMemPrefetchAsync)', 'libgomp/plugin/cuda-lib.def' should specify 'CUDA_ONE_CALL_MAYBE_NULL (cuMemPrefetchAsync)', which for '!PLUGIN_NVPTX_DYNAMIC' configurations would make sure to provide a 'weak' prototype for 'cuMemPrefetchAsync', and then ought to check 'CUDA_CALL_EXISTS (cuMemPrefetchAsync)' before doing 'CUDA_CALL (cuMemPrefetchAsync)'. So: all is good, my scenario can be made work correctly even for the '--with-cuda-driver' case: at run-time we see whether 'cuMemPrefetchAsync' is available, and only call if it is -- no matter how the CUDA Driver library gets linked ('-lcuda') or loaded ('dlopen'). Anyway, despite that, we seem to agree that '--with-cuda-driver' is not very useful, and may be removed: >> Already long ago Jakub put in changes to use '--without-cuda-driver' to >> "Allow building GCC with PTX offloading even without CUDA being installed >> (gcc and nvptx-tools patches)": "Especially for distributions it is >> undesirable to need to have proprietary CUDA libraries and headers >> installed when building GCC.", and I understand GNU/Linux distributions >> all use that. That configuration uses the GCC-provided >> 'libgomp/plugin/cuda/cuda.h', 'libgomp/plugin/cuda-lib.def' to manually >> define the CUDA Driver ABI to use, and then 'dlopen("libcuda.so.1")'. >> (Similar to what the libgomp GCN (and before: HSA) plugin is doing, for >> example.) Quite likely that our group (at work) are the only ones to >> actually use '--with-cuda-driver'? > > Right, I see in my scripts that I don't use --with-cuda-driver, possibly > because of years-ago running into issues when changing drivers forth and > back. > >> My proposal now is: we remove '--with-cuda-driver' (make its use a no-op, >> per standard GNU Autoconf behavior), and offer '--without-cuda-driver' >> only. This shouldn't cause any user-visible change in behavior, so safe >> without a prior deprecation phase. > > I think the dlopen use-case is the most flexible, and I don't see any > user benefit from using --with-cuda-driver, so I don't see a problem > with removing --with-cuda-driver for the user. ACK, thanks. > I did wonder about keeping it available in some form, say rename to > --maintainer-mode-with-cuda-driver. This could be useful for debugging > / comparison purposes. But it would mean having to test it when making > relevant changes, which is maintenance burden for a feature not visible > to the user, so I guess that's not worth it. > > So, I'm fine with removing. Based on the point you made above, I realized that it may be beneficial to "keep the underlying functionality available for the developers": "if you develop CUDA API-level changes in the libgomp nvptx plugin, it's likely to be easier to just use the full CUDA toolkit 'cuda.h' and directly link against libcuda (so that you've got all symbols etc. available), and only once you know what exactly you need, update GCC's 'include/cuda/cuda.h' and 'libgomp/plugin/cuda-lib.def'". (See the thread "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'".) Do we agree that it's OK to remove the user-visiable '--with-cuda-driver' etc. options, and do not introduce any new '--enable-maintainer-mode-with-cuda-driver' (or similar) option, and instead let this functionality be available to developers only, via manually editing 'libgomp/plugin/Makefrag.am'? Happy to submit an illustrative patch, if that helps. Grüße Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 ^ permalink raw reply [flat|nested] 9+ messages in thread
* libgomp nvptx plugin: Remove '--with-cuda-driver=[...]' etc. configuration option (was: Proposal to remove '--with-cuda-driver') 2022-04-29 13:48 ` Proposal to remove '--with-cuda-driver' Thomas Schwinge @ 2022-05-13 12:29 ` Thomas Schwinge 2022-05-27 11:57 ` [PING] " Thomas Schwinge 0 siblings, 1 reply; 9+ messages in thread From: Thomas Schwinge @ 2022-05-13 12:29 UTC (permalink / raw) To: Tom de Vries, Jakub Jelinek, gcc-patches; +Cc: Tobias Burnus, Roger Sayle [-- Attachment #1: Type: text/plain, Size: 3892 bytes --] Hi! On 2022-04-29T15:48:03+0200, I wrote: > On 2022-04-06T11:57:57+0200, Tom de Vries <tdevries@suse.de> wrote: >> On 4/5/22 17:14, Thomas Schwinge wrote: >>> Regarding [...] >>> Now, consider doing a GCC/nvptx offloading build with >>> '--with-cuda-driver' [...] >> Thanks for reminding me, I forgot about this configure option. > > OK, good. ;-) (It also wasn't documented, by the way...) > [...] we seem to agree that '--with-cuda-driver' is not > very useful, and may be removed: > >>> Already long ago Jakub put in changes to use '--without-cuda-driver' to >>> "Allow building GCC with PTX offloading even without CUDA being installed >>> (gcc and nvptx-tools patches)": "Especially for distributions it is >>> undesirable to need to have proprietary CUDA libraries and headers >>> installed when building GCC.", and I understand GNU/Linux distributions >>> all use that. That configuration uses the GCC-provided >>> 'libgomp/plugin/cuda/cuda.h', 'libgomp/plugin/cuda-lib.def' to manually >>> define the CUDA Driver ABI to use, and then 'dlopen("libcuda.so.1")'. >>> (Similar to what the libgomp GCN (and before: HSA) plugin is doing, for >>> example.) Quite likely that our group (at work) are the only ones to >>> actually use '--with-cuda-driver'? >> >> Right, I see in my scripts that I don't use --with-cuda-driver, possibly >> because of years-ago running into issues when changing drivers forth and >> back. >> >>> My proposal now is: we remove '--with-cuda-driver' (make its use a no-op, >>> per standard GNU Autoconf behavior), and offer '--without-cuda-driver' >>> only. This shouldn't cause any user-visible change in behavior, so safe >>> without a prior deprecation phase. >> >> I think the dlopen use-case is the most flexible, and I don't see any >> user benefit from using --with-cuda-driver, so I don't see a problem >> with removing --with-cuda-driver for the user. > > ACK, thanks. > >> I did wonder about keeping it available in some form, say rename to >> --maintainer-mode-with-cuda-driver. This could be useful for debugging >> / comparison purposes. But it would mean having to test it when making >> relevant changes, which is maintenance burden for a feature not visible >> to the user, so I guess that's not worth it. >> >> So, I'm fine with removing. > > Based on the point you made above, I realized that it may be beneficial > to "keep the underlying functionality available for the developers": > "if you develop CUDA API-level changes in the libgomp nvptx plugin, it's > likely to be easier to just use the full CUDA toolkit 'cuda.h' and > directly link against libcuda (so that you've got all symbols etc. > available), and only once you know what exactly you need, update GCC's > 'include/cuda/cuda.h' and 'libgomp/plugin/cuda-lib.def'". (See the > thread "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into > 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'".) > > Do we agree that it's OK to remove the user-visiable '--with-cuda-driver' > etc. options, and do not introduce any new > '--enable-maintainer-mode-with-cuda-driver' (or similar) option, and > instead let this functionality be available to developers only, via > manually editing 'libgomp/plugin/Makefrag.am'? > > Happy to submit an illustrative patch, if that helps. Well, given the preparational work that I've put in in the last days, attached now actually is the final patch: "libgomp nvptx plugin: Remove '--with-cuda-driver=[...]' etc. configuration option". OK to push? Grüße Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-libgomp-nvptx-plugin-Remove-with-cuda-driver-.-etc.-.patch --] [-- Type: text/x-diff, Size: 20150 bytes --] From 68f307775254e468b0aea3209e7e34528fa92bfc Mon Sep 17 00:00:00 2001 From: Thomas Schwinge <thomas@codesourcery.com> Date: Thu, 12 May 2022 22:46:40 +0200 Subject: [PATCH] libgomp nvptx plugin: Remove '--with-cuda-driver=[...]' etc. configuration option That means, exposing to the user only the '--without-cuda-driver' behavior: including the GCC-shipped 'include/cuda/cuda.h' (not system <cuda.h>), and 'dlopen'ing the CUDA Driver library (not linking it). For development purposes, the libgomp nvptx plugin developer may still manually override that, to get the previous '--with-cuda-driver' behavior. libgomp/ * plugin/Makefrag.am: Evaluate 'if PLUGIN_NVPTX_DYNAMIC' to true. * plugin/configfrag.ac (--with-cuda-driver) (--with-cuda-driver-include, --with-cuda-driver-lib) (CUDA_DRIVER_INCLUDE, CUDA_DRIVER_LIB, PLUGIN_NVPTX_CPPFLAGS) (PLUGIN_NVPTX_LDFLAGS, PLUGIN_NVPTX_LIBS, PLUGIN_NVPTX_DYNAMIC): Remove. * testsuite/libgomp-test-support.exp.in (cuda_driver_include) (cuda_driver_lib): Remove. * testsuite/lib/libgomp.exp (libgomp_init): Don't consider these. * Makefile.in: Regenerate. * configure: Likewise. * testsuite/Makefile.in: Likewise. --- libgomp/Makefile.in | 50 +++--- libgomp/configure | 143 +----------------- libgomp/plugin/Makefrag.am | 25 ++- libgomp/plugin/configfrag.ac | 90 +---------- libgomp/testsuite/Makefile.in | 5 - libgomp/testsuite/lib/libgomp.exp | 13 -- libgomp/testsuite/libgomp-test-support.exp.in | 3 - 7 files changed, 37 insertions(+), 292 deletions(-) diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in index 2ac0397a036..8f6255f2d70 100644 --- a/libgomp/Makefile.in +++ b/libgomp/Makefile.in @@ -119,18 +119,8 @@ build_triplet = @build@ host_triplet = @host@ target_triplet = @target@ @PLUGIN_NVPTX_TRUE@am__append_1 = libgomp-plugin-nvptx.la - -# Including the GCC-shipped 'include/cuda/cuda.h' vs. system <cuda.h>. -@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__append_2 = -DPLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H \ -@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@ $(PLUGIN_NVPTX_CPPFLAGS) \ -@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@ -DPLUGIN_NVPTX_LINK_LIBCUDA - -# 'dlopen'ing the CUDA Driver library vs. linking it. -@PLUGIN_NVPTX_DYNAMIC_TRUE@@PLUGIN_NVPTX_TRUE@am__append_3 = $(DL_LIBS) -@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__append_4 = $(PLUGIN_NVPTX_LDFLAGS) -@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__append_5 = $(PLUGIN_NVPTX_LIBS) -@PLUGIN_GCN_TRUE@am__append_6 = libgomp-plugin-gcn.la -@USE_FORTRAN_TRUE@am__append_7 = openacc.f90 +@PLUGIN_GCN_TRUE@am__append_2 = libgomp-plugin-gcn.la +@USE_FORTRAN_TRUE@am__append_3 = openacc.f90 subdir = . ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \ @@ -207,10 +197,8 @@ libgomp_plugin_gcn_la_LINK = $(LIBTOOL) $(AM_V_lt) --tag=CC \ $(libgomp_plugin_gcn_la_LDFLAGS) $(LDFLAGS) -o $@ @PLUGIN_GCN_TRUE@am_libgomp_plugin_gcn_la_rpath = -rpath \ @PLUGIN_GCN_TRUE@ $(toolexeclibdir) -@PLUGIN_NVPTX_DYNAMIC_TRUE@@PLUGIN_NVPTX_TRUE@am__DEPENDENCIES_2 = $(am__DEPENDENCIES_1) -@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__DEPENDENCIES_3 = $(am__DEPENDENCIES_1) @PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_DEPENDENCIES = libgomp.la \ -@PLUGIN_NVPTX_TRUE@ $(am__DEPENDENCIES_2) $(am__DEPENDENCIES_3) +@PLUGIN_NVPTX_TRUE@ $(am__DEPENDENCIES_1) @PLUGIN_NVPTX_TRUE@am_libgomp_plugin_nvptx_la_OBJECTS = \ @PLUGIN_NVPTX_TRUE@ libgomp_plugin_nvptx_la-plugin-nvptx.lo libgomp_plugin_nvptx_la_OBJECTS = \ @@ -380,8 +368,6 @@ CFLAGS = @CFLAGS@ CPP = @CPP@ CPPFLAGS = @CPPFLAGS@ CPU_COUNT = @CPU_COUNT@ -CUDA_DRIVER_INCLUDE = @CUDA_DRIVER_INCLUDE@ -CUDA_DRIVER_LIB = @CUDA_DRIVER_LIB@ CYGPATH_W = @CYGPATH_W@ DEFS = @DEFS@ DEPDIR = @DEPDIR@ @@ -443,9 +429,6 @@ PACKAGE_URL = @PACKAGE_URL@ PACKAGE_VERSION = @PACKAGE_VERSION@ PATH_SEPARATOR = @PATH_SEPARATOR@ PERL = @PERL@ -PLUGIN_NVPTX_CPPFLAGS = @PLUGIN_NVPTX_CPPFLAGS@ -PLUGIN_NVPTX_LDFLAGS = @PLUGIN_NVPTX_LDFLAGS@ -PLUGIN_NVPTX_LIBS = @PLUGIN_NVPTX_LIBS@ RANLIB = @RANLIB@ SECTION_LDFLAGS = @SECTION_LDFLAGS@ SED = @SED@ @@ -538,7 +521,7 @@ libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include AM_CPPFLAGS = $(addprefix -I, $(search_path)) AM_CFLAGS = $(XCFLAGS) AM_LDFLAGS = $(XLDFLAGS) $(SECTION_LDFLAGS) $(OPT_LDFLAGS) -toolexeclib_LTLIBRARIES = libgomp.la $(am__append_1) $(am__append_6) +toolexeclib_LTLIBRARIES = libgomp.la $(am__append_1) $(am__append_2) nodist_toolexeclib_HEADERS = libgomp.spec # -Wc is only a libtool option. @@ -565,19 +548,30 @@ libgomp_la_SOURCES = alloc.c atomic.c barrier.c critical.c env.c \ oacc-parallel.c oacc-host.c oacc-init.c oacc-mem.c \ oacc-async.c oacc-plugin.c oacc-cuda.c priority_queue.c \ affinity-fmt.c teams.c allocator.c oacc-profiling.c \ - oacc-target.c $(am__append_7) + oacc-target.c $(am__append_3) # Nvidia PTX OpenACC plugin. @PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_version_info = -version-info $(libtool_VERSION) @PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_SOURCES = plugin/plugin-nvptx.c -@PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_CPPFLAGS = $(AM_CPPFLAGS) \ -@PLUGIN_NVPTX_TRUE@ $(am__append_2) -@PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_LDFLAGS = \ -@PLUGIN_NVPTX_TRUE@ $(libgomp_plugin_nvptx_version_info) \ -@PLUGIN_NVPTX_TRUE@ $(lt_host_flags) $(am__append_4) +@PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_CPPFLAGS = $(AM_CPPFLAGS) +@PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_LDFLAGS = $(libgomp_plugin_nvptx_version_info) \ +@PLUGIN_NVPTX_TRUE@ $(lt_host_flags) + + +# libgomp nvptx plugin developer's section. +# +# Including the GCC-shipped 'include/cuda/cuda.h' (default) vs. system <cuda.h>: +#libgomp_plugin_nvptx_la_CPPFLAGS += -DPLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H +#libgomp_plugin_nvptx_la_CPPFLAGS += -I[CUDA]/include +# +# 'dlopen'ing the CUDA Driver library (default): @PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_LIBADD = libgomp.la \ -@PLUGIN_NVPTX_TRUE@ $(am__append_3) $(am__append_5) +@PLUGIN_NVPTX_TRUE@ $(DL_LIBS) @PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_LIBTOOLFLAGS = --tag=disable-static +# ... vs. linking it: +#libgomp_plugin_nvptx_la_CPPFLAGS += -DPLUGIN_NVPTX_LINK_LIBCUDA +#libgomp_plugin_nvptx_la_LDFLAGS += -L[CUDA]/lib64/stubs +#libgomp_plugin_nvptx_la_LIBADD += -lcuda # AMD GCN plugin @PLUGIN_GCN_TRUE@libgomp_plugin_gcn_version_info = -version-info $(libtool_VERSION) diff --git a/libgomp/configure b/libgomp/configure index 66dface222e..89f14e441f2 100755 --- a/libgomp/configure +++ b/libgomp/configure @@ -667,19 +667,12 @@ OPT_LDFLAGS SECTION_LDFLAGS PLUGIN_GCN_FALSE PLUGIN_GCN_TRUE -PLUGIN_NVPTX_DYNAMIC_FALSE -PLUGIN_NVPTX_DYNAMIC_TRUE PLUGIN_NVPTX_FALSE PLUGIN_NVPTX_TRUE offload_additional_lib_paths offload_additional_options offload_targets offload_plugins -PLUGIN_NVPTX_LIBS -PLUGIN_NVPTX_LDFLAGS -PLUGIN_NVPTX_CPPFLAGS -CUDA_DRIVER_LIB -CUDA_DRIVER_INCLUDE DL_LIBS libtool_VERSION ac_ct_FC @@ -829,9 +822,6 @@ enable_fast_install with_gnu_ld enable_libtool_lock enable_maintainer_mode -with_cuda_driver -with_cuda_driver_include -with_cuda_driver_lib enable_linux_futex enable_tls enable_symvers @@ -1504,16 +1494,6 @@ Optional Packages: --with-pic try to use only PIC/non-PIC objects [default=use both] --with-gnu-ld assume the C compiler uses GNU ld [default=no] - --with-cuda-driver=PATH specify prefix directory for installed CUDA driver - package. Equivalent to - --with-cuda-driver-include=PATH/include plus - --with-cuda-driver-lib=PATH/lib - --with-cuda-driver-include=PATH - specify directory for installed CUDA driver include - files - --with-cuda-driver-lib=PATH - specify directory for the installed CUDA driver - library --with-gcc-major-version-only use only GCC major number in filesystem paths @@ -11414,7 +11394,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 11417 "configure" +#line 11397 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -11520,7 +11500,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 11523 "configure" +#line 11503 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -15158,67 +15138,8 @@ done -# Look for the CUDA driver package. -CUDA_DRIVER_INCLUDE= -CUDA_DRIVER_LIB= - - -CUDA_DRIVER_CPPFLAGS= -CUDA_DRIVER_LDFLAGS= - -# Check whether --with-cuda-driver was given. -if test "${with_cuda_driver+set}" = set; then : - withval=$with_cuda_driver; -fi - - -# Check whether --with-cuda-driver-include was given. -if test "${with_cuda_driver_include+set}" = set; then : - withval=$with_cuda_driver_include; -fi - - -# Check whether --with-cuda-driver-lib was given. -if test "${with_cuda_driver_lib+set}" = set; then : - withval=$with_cuda_driver_lib; -fi - -case "x$with_cuda_driver" in - x) ;; - xno) - CUDA_DRIVER_INCLUDE=no - CUDA_DRIVER_LIB=no - ;; - *) CUDA_DRIVER_INCLUDE=$with_cuda_driver/include - CUDA_DRIVER_LIB=$with_cuda_driver/lib - ;; -esac -if test "x$with_cuda_driver_include" != x; then - CUDA_DRIVER_INCLUDE=$with_cuda_driver_include -fi -if test "x$with_cuda_driver_lib" != x; then - CUDA_DRIVER_LIB=$with_cuda_driver_lib -fi -if test "x$CUDA_DRIVER_INCLUDE" != x \ - && test "x$CUDA_DRIVER_INCLUDE" != xno; then - CUDA_DRIVER_CPPFLAGS=-I$CUDA_DRIVER_INCLUDE -fi -if test "x$CUDA_DRIVER_LIB" != x \ - && test "x$CUDA_DRIVER_LIB" != xno; then - CUDA_DRIVER_LDFLAGS=-L$CUDA_DRIVER_LIB -fi - PLUGIN_NVPTX=0 -PLUGIN_NVPTX_CPPFLAGS= -PLUGIN_NVPTX_LDFLAGS= -PLUGIN_NVPTX_LIBS= -PLUGIN_NVPTX_DYNAMIC=0 - - - - PLUGIN_GCN=0 - # Parse '--enable-offload-targets', figure out the corresponding libgomp # plugins, and configure to find the corresponding offload compilers. # 'offload_plugins' and 'offload_targets' will be populated in the same order. @@ -15250,53 +15171,7 @@ if test x"$enable_offload_targets" != x; then ;; *) tgt_plugin=nvptx - PLUGIN_NVPTX=$tgt - if test "x$CUDA_DRIVER_LIB" != xno \ - && test "x$CUDA_DRIVER_LIB" != xno; then - PLUGIN_NVPTX_CPPFLAGS=$CUDA_DRIVER_CPPFLAGS - PLUGIN_NVPTX_LDFLAGS=$CUDA_DRIVER_LDFLAGS - PLUGIN_NVPTX_LIBS='-lcuda' - - PLUGIN_NVPTX_save_CPPFLAGS=$CPPFLAGS - CPPFLAGS="$PLUGIN_NVPTX_CPPFLAGS $CPPFLAGS" - PLUGIN_NVPTX_save_LDFLAGS=$LDFLAGS - LDFLAGS="$PLUGIN_NVPTX_LDFLAGS $LDFLAGS" - PLUGIN_NVPTX_save_LIBS=$LIBS - LIBS="$PLUGIN_NVPTX_LIBS $LIBS" - cat confdefs.h - <<_ACEOF >conftest.$ac_ext -/* end confdefs.h. */ -#include "cuda.h" -int -main () -{ -CUresult r = cuCtxPushCurrent (NULL); - ; - return 0; -} -_ACEOF -if ac_fn_c_try_link "$LINENO"; then : - PLUGIN_NVPTX=1 -fi -rm -f core conftest.err conftest.$ac_objext \ - conftest$ac_exeext conftest.$ac_ext - CPPFLAGS=$PLUGIN_NVPTX_save_CPPFLAGS - LDFLAGS=$PLUGIN_NVPTX_save_LDFLAGS - LIBS=$PLUGIN_NVPTX_save_LIBS - fi - case $PLUGIN_NVPTX in - nvptx*) - if (test "x$CUDA_DRIVER_INCLUDE" = x \ - || test "x$CUDA_DRIVER_INCLUDE" = xno) \ - && (test "x$CUDA_DRIVER_LIB" = x \ - || test "x$CUDA_DRIVER_LIB" = xno); then - PLUGIN_NVPTX=1 - PLUGIN_NVPTX_DYNAMIC=1 - else - PLUGIN_NVPTX=0 - as_fn_error $? "CUDA driver package required for nvptx support" "$LINENO" 5 - fi - ;; - esac + PLUGIN_NVPTX=1 ;; esac ;; @@ -15362,14 +15237,6 @@ else PLUGIN_NVPTX_FALSE= fi - if test $PLUGIN_NVPTX_DYNAMIC = 1; then - PLUGIN_NVPTX_DYNAMIC_TRUE= - PLUGIN_NVPTX_DYNAMIC_FALSE='#' -else - PLUGIN_NVPTX_DYNAMIC_TRUE='#' - PLUGIN_NVPTX_DYNAMIC_FALSE= -fi - if test $PLUGIN_GCN = 1; then PLUGIN_GCN_TRUE= PLUGIN_GCN_FALSE='#' @@ -17137,10 +17004,6 @@ if test -z "${PLUGIN_NVPTX_TRUE}" && test -z "${PLUGIN_NVPTX_FALSE}"; then as_fn_error $? "conditional \"PLUGIN_NVPTX\" was never defined. Usually this means the macro was only invoked conditionally." "$LINENO" 5 fi -if test -z "${PLUGIN_NVPTX_DYNAMIC_TRUE}" && test -z "${PLUGIN_NVPTX_DYNAMIC_FALSE}"; then - as_fn_error $? "conditional \"PLUGIN_NVPTX_DYNAMIC\" was never defined. -Usually this means the macro was only invoked conditionally." "$LINENO" 5 -fi if test -z "${PLUGIN_GCN_TRUE}" && test -z "${PLUGIN_GCN_FALSE}"; then as_fn_error $? "conditional \"PLUGIN_GCN\" was never defined. Usually this means the macro was only invoked conditionally." "$LINENO" 5 diff --git a/libgomp/plugin/Makefrag.am b/libgomp/plugin/Makefrag.am index 66c8c12c1a6..5aad9ab5d8b 100644 --- a/libgomp/plugin/Makefrag.am +++ b/libgomp/plugin/Makefrag.am @@ -39,21 +39,18 @@ libgomp_plugin_nvptx_la_LDFLAGS = $(libgomp_plugin_nvptx_version_info) \ libgomp_plugin_nvptx_la_LIBADD = libgomp.la libgomp_plugin_nvptx_la_LIBTOOLFLAGS = --tag=disable-static -# Including the GCC-shipped 'include/cuda/cuda.h' vs. system <cuda.h>. -if PLUGIN_NVPTX_DYNAMIC -else -libgomp_plugin_nvptx_la_CPPFLAGS += -DPLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H -libgomp_plugin_nvptx_la_CPPFLAGS += $(PLUGIN_NVPTX_CPPFLAGS) -endif - -# 'dlopen'ing the CUDA Driver library vs. linking it. -if PLUGIN_NVPTX_DYNAMIC +# libgomp nvptx plugin developer's section. +# +# Including the GCC-shipped 'include/cuda/cuda.h' (default) vs. system <cuda.h>: +#libgomp_plugin_nvptx_la_CPPFLAGS += -DPLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H +#libgomp_plugin_nvptx_la_CPPFLAGS += -I[CUDA]/include +# +# 'dlopen'ing the CUDA Driver library (default): libgomp_plugin_nvptx_la_LIBADD += $(DL_LIBS) -else -libgomp_plugin_nvptx_la_CPPFLAGS += -DPLUGIN_NVPTX_LINK_LIBCUDA -libgomp_plugin_nvptx_la_LDFLAGS += $(PLUGIN_NVPTX_LDFLAGS) -libgomp_plugin_nvptx_la_LIBADD += $(PLUGIN_NVPTX_LIBS) -endif +# ... vs. linking it: +#libgomp_plugin_nvptx_la_CPPFLAGS += -DPLUGIN_NVPTX_LINK_LIBCUDA +#libgomp_plugin_nvptx_la_LDFLAGS += -L[CUDA]/lib64/stubs +#libgomp_plugin_nvptx_la_LIBADD += -lcuda endif if PLUGIN_GCN diff --git a/libgomp/plugin/configfrag.ac b/libgomp/plugin/configfrag.ac index 14203048bdb..ab03f94adac 100644 --- a/libgomp/plugin/configfrag.ac +++ b/libgomp/plugin/configfrag.ac @@ -40,60 +40,8 @@ AC_CHECK_HEADERS_ONCE(unistd.h) AC_CHECK_FUNCS_ONCE(secure_getenv __secure_getenv getuid geteuid getgid getegid) -# Look for the CUDA driver package. -CUDA_DRIVER_INCLUDE= -CUDA_DRIVER_LIB= -AC_SUBST(CUDA_DRIVER_INCLUDE) -AC_SUBST(CUDA_DRIVER_LIB) -CUDA_DRIVER_CPPFLAGS= -CUDA_DRIVER_LDFLAGS= -AC_ARG_WITH(cuda-driver, - [AS_HELP_STRING([--with-cuda-driver=PATH], - [specify prefix directory for installed CUDA driver package. - Equivalent to --with-cuda-driver-include=PATH/include - plus --with-cuda-driver-lib=PATH/lib])]) -AC_ARG_WITH(cuda-driver-include, - [AS_HELP_STRING([--with-cuda-driver-include=PATH], - [specify directory for installed CUDA driver include files])]) -AC_ARG_WITH(cuda-driver-lib, - [AS_HELP_STRING([--with-cuda-driver-lib=PATH], - [specify directory for the installed CUDA driver library])]) -case "x$with_cuda_driver" in - x) ;; - xno) - CUDA_DRIVER_INCLUDE=no - CUDA_DRIVER_LIB=no - ;; - *) CUDA_DRIVER_INCLUDE=$with_cuda_driver/include - CUDA_DRIVER_LIB=$with_cuda_driver/lib - ;; -esac -if test "x$with_cuda_driver_include" != x; then - CUDA_DRIVER_INCLUDE=$with_cuda_driver_include -fi -if test "x$with_cuda_driver_lib" != x; then - CUDA_DRIVER_LIB=$with_cuda_driver_lib -fi -if test "x$CUDA_DRIVER_INCLUDE" != x \ - && test "x$CUDA_DRIVER_INCLUDE" != xno; then - CUDA_DRIVER_CPPFLAGS=-I$CUDA_DRIVER_INCLUDE -fi -if test "x$CUDA_DRIVER_LIB" != x \ - && test "x$CUDA_DRIVER_LIB" != xno; then - CUDA_DRIVER_LDFLAGS=-L$CUDA_DRIVER_LIB -fi - PLUGIN_NVPTX=0 -PLUGIN_NVPTX_CPPFLAGS= -PLUGIN_NVPTX_LDFLAGS= -PLUGIN_NVPTX_LIBS= -PLUGIN_NVPTX_DYNAMIC=0 -AC_SUBST(PLUGIN_NVPTX_CPPFLAGS) -AC_SUBST(PLUGIN_NVPTX_LDFLAGS) -AC_SUBST(PLUGIN_NVPTX_LIBS) - PLUGIN_GCN=0 - # Parse '--enable-offload-targets', figure out the corresponding libgomp # plugins, and configure to find the corresponding offload compilers. # 'offload_plugins' and 'offload_targets' will be populated in the same order. @@ -125,42 +73,7 @@ if test x"$enable_offload_targets" != x; then ;; *) tgt_plugin=nvptx - PLUGIN_NVPTX=$tgt - if test "x$CUDA_DRIVER_LIB" != xno \ - && test "x$CUDA_DRIVER_LIB" != xno; then - PLUGIN_NVPTX_CPPFLAGS=$CUDA_DRIVER_CPPFLAGS - PLUGIN_NVPTX_LDFLAGS=$CUDA_DRIVER_LDFLAGS - PLUGIN_NVPTX_LIBS='-lcuda' - - PLUGIN_NVPTX_save_CPPFLAGS=$CPPFLAGS - CPPFLAGS="$PLUGIN_NVPTX_CPPFLAGS $CPPFLAGS" - PLUGIN_NVPTX_save_LDFLAGS=$LDFLAGS - LDFLAGS="$PLUGIN_NVPTX_LDFLAGS $LDFLAGS" - PLUGIN_NVPTX_save_LIBS=$LIBS - LIBS="$PLUGIN_NVPTX_LIBS $LIBS" - AC_LINK_IFELSE( - [AC_LANG_PROGRAM( - [#include "cuda.h"], - [CUresult r = cuCtxPushCurrent (NULL);])], - [PLUGIN_NVPTX=1]) - CPPFLAGS=$PLUGIN_NVPTX_save_CPPFLAGS - LDFLAGS=$PLUGIN_NVPTX_save_LDFLAGS - LIBS=$PLUGIN_NVPTX_save_LIBS - fi - case $PLUGIN_NVPTX in - nvptx*) - if (test "x$CUDA_DRIVER_INCLUDE" = x \ - || test "x$CUDA_DRIVER_INCLUDE" = xno) \ - && (test "x$CUDA_DRIVER_LIB" = x \ - || test "x$CUDA_DRIVER_LIB" = xno); then - PLUGIN_NVPTX=1 - PLUGIN_NVPTX_DYNAMIC=1 - else - PLUGIN_NVPTX=0 - AC_MSG_ERROR([CUDA driver package required for nvptx support]) - fi - ;; - esac + PLUGIN_NVPTX=1 ;; esac ;; @@ -216,5 +129,4 @@ fi AC_DEFINE_UNQUOTED(OFFLOAD_PLUGINS, "$offload_plugins", [Define to offload plugins, separated by commas.]) AM_CONDITIONAL([PLUGIN_NVPTX], [test $PLUGIN_NVPTX = 1]) -AM_CONDITIONAL([PLUGIN_NVPTX_DYNAMIC], [test $PLUGIN_NVPTX_DYNAMIC = 1]) AM_CONDITIONAL([PLUGIN_GCN], [test $PLUGIN_GCN = 1]) diff --git a/libgomp/testsuite/Makefile.in b/libgomp/testsuite/Makefile.in index 048844f0a40..7a88f0fe5c6 100644 --- a/libgomp/testsuite/Makefile.in +++ b/libgomp/testsuite/Makefile.in @@ -147,8 +147,6 @@ CFLAGS = @CFLAGS@ CPP = @CPP@ CPPFLAGS = @CPPFLAGS@ CPU_COUNT = @CPU_COUNT@ -CUDA_DRIVER_INCLUDE = @CUDA_DRIVER_INCLUDE@ -CUDA_DRIVER_LIB = @CUDA_DRIVER_LIB@ CYGPATH_W = @CYGPATH_W@ DEFS = @DEFS@ DEPDIR = @DEPDIR@ @@ -210,9 +208,6 @@ PACKAGE_URL = @PACKAGE_URL@ PACKAGE_VERSION = @PACKAGE_VERSION@ PATH_SEPARATOR = @PATH_SEPARATOR@ PERL = @PERL@ -PLUGIN_NVPTX_CPPFLAGS = @PLUGIN_NVPTX_CPPFLAGS@ -PLUGIN_NVPTX_LDFLAGS = @PLUGIN_NVPTX_LDFLAGS@ -PLUGIN_NVPTX_LIBS = @PLUGIN_NVPTX_LIBS@ RANLIB = @RANLIB@ SECTION_LDFLAGS = @SECTION_LDFLAGS@ SED = @SED@ diff --git a/libgomp/testsuite/lib/libgomp.exp b/libgomp/testsuite/lib/libgomp.exp index 0aaa58f19c5..11c90766704 100644 --- a/libgomp/testsuite/lib/libgomp.exp +++ b/libgomp/testsuite/lib/libgomp.exp @@ -189,19 +189,6 @@ proc libgomp_init { args } { append always_ld_library_path ":${atomic_library_path}" } } - global cuda_driver_include - global cuda_driver_lib - if { $cuda_driver_include != "" } { - # Stop gfortran from freaking out: - # Warning: Nonexistent include directory "[...]" - if {[file exists $cuda_driver_include]} { - lappend ALWAYS_CFLAGS "additional_flags=-I$cuda_driver_include" - } - } - if { $cuda_driver_lib != "" } { - lappend ALWAYS_CFLAGS "additional_flags=-L$cuda_driver_lib" - append always_ld_library_path ":$cuda_driver_lib" - } } # We use atomic operations in the testcases to validate results. diff --git a/libgomp/testsuite/libgomp-test-support.exp.in b/libgomp/testsuite/libgomp-test-support.exp.in index 3c88d1d5a62..36615b353aa 100644 --- a/libgomp/testsuite/libgomp-test-support.exp.in +++ b/libgomp/testsuite/libgomp-test-support.exp.in @@ -1,5 +1,2 @@ -set cuda_driver_include "@CUDA_DRIVER_INCLUDE@" -set cuda_driver_lib "@CUDA_DRIVER_LIB@" - set offload_plugins "@offload_plugins@" set offload_targets "@offload_targets@" -- 2.35.1 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PING] libgomp nvptx plugin: Remove '--with-cuda-driver=[...]' etc. configuration option (was: Proposal to remove '--with-cuda-driver') 2022-05-13 12:29 ` libgomp nvptx plugin: Remove '--with-cuda-driver=[...]' etc. configuration option (was: Proposal to remove '--with-cuda-driver') Thomas Schwinge @ 2022-05-27 11:57 ` Thomas Schwinge 0 siblings, 0 replies; 9+ messages in thread From: Thomas Schwinge @ 2022-05-27 11:57 UTC (permalink / raw) To: Tom de Vries, Jakub Jelinek, gcc-patches; +Cc: Tobias Burnus, Roger Sayle [-- Attachment #1: Type: text/plain, Size: 4060 bytes --] Hi! Ping. Grüße Thomas On 2022-05-13T14:29:01+0200, I wrote: > Hi! > > On 2022-04-29T15:48:03+0200, I wrote: >> On 2022-04-06T11:57:57+0200, Tom de Vries <tdevries@suse.de> wrote: >>> On 4/5/22 17:14, Thomas Schwinge wrote: >>>> Regarding [...] > >>>> Now, consider doing a GCC/nvptx offloading build with >>>> '--with-cuda-driver' [...] > >>> Thanks for reminding me, I forgot about this configure option. >> >> OK, good. ;-) > > (It also wasn't documented, by the way...) > >> [...] we seem to agree that '--with-cuda-driver' is not >> very useful, and may be removed: >> >>>> Already long ago Jakub put in changes to use '--without-cuda-driver' to >>>> "Allow building GCC with PTX offloading even without CUDA being installed >>>> (gcc and nvptx-tools patches)": "Especially for distributions it is >>>> undesirable to need to have proprietary CUDA libraries and headers >>>> installed when building GCC.", and I understand GNU/Linux distributions >>>> all use that. That configuration uses the GCC-provided >>>> 'libgomp/plugin/cuda/cuda.h', 'libgomp/plugin/cuda-lib.def' to manually >>>> define the CUDA Driver ABI to use, and then 'dlopen("libcuda.so.1")'. >>>> (Similar to what the libgomp GCN (and before: HSA) plugin is doing, for >>>> example.) Quite likely that our group (at work) are the only ones to >>>> actually use '--with-cuda-driver'? >>> >>> Right, I see in my scripts that I don't use --with-cuda-driver, possibly >>> because of years-ago running into issues when changing drivers forth and >>> back. >>> >>>> My proposal now is: we remove '--with-cuda-driver' (make its use a no-op, >>>> per standard GNU Autoconf behavior), and offer '--without-cuda-driver' >>>> only. This shouldn't cause any user-visible change in behavior, so safe >>>> without a prior deprecation phase. >>> >>> I think the dlopen use-case is the most flexible, and I don't see any >>> user benefit from using --with-cuda-driver, so I don't see a problem >>> with removing --with-cuda-driver for the user. >> >> ACK, thanks. >> >>> I did wonder about keeping it available in some form, say rename to >>> --maintainer-mode-with-cuda-driver. This could be useful for debugging >>> / comparison purposes. But it would mean having to test it when making >>> relevant changes, which is maintenance burden for a feature not visible >>> to the user, so I guess that's not worth it. >>> >>> So, I'm fine with removing. >> >> Based on the point you made above, I realized that it may be beneficial >> to "keep the underlying functionality available for the developers": >> "if you develop CUDA API-level changes in the libgomp nvptx plugin, it's >> likely to be easier to just use the full CUDA toolkit 'cuda.h' and >> directly link against libcuda (so that you've got all symbols etc. >> available), and only once you know what exactly you need, update GCC's >> 'include/cuda/cuda.h' and 'libgomp/plugin/cuda-lib.def'". (See the >> thread "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into >> 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'".) >> >> Do we agree that it's OK to remove the user-visiable '--with-cuda-driver' >> etc. options, and do not introduce any new >> '--enable-maintainer-mode-with-cuda-driver' (or similar) option, and >> instead let this functionality be available to developers only, via >> manually editing 'libgomp/plugin/Makefrag.am'? >> >> Happy to submit an illustrative patch, if that helps. > > Well, given the preparational work that I've put in in the last days, > attached now actually is the final patch: "libgomp nvptx plugin: > Remove '--with-cuda-driver=[...]' etc. configuration option". OK to > push? > > > Grüße > Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-libgomp-nvptx-plugin-Remove-with-cuda-driver-.-etc.-.patch --] [-- Type: text/x-diff, Size: 20150 bytes --] From 68f307775254e468b0aea3209e7e34528fa92bfc Mon Sep 17 00:00:00 2001 From: Thomas Schwinge <thomas@codesourcery.com> Date: Thu, 12 May 2022 22:46:40 +0200 Subject: [PATCH] libgomp nvptx plugin: Remove '--with-cuda-driver=[...]' etc. configuration option That means, exposing to the user only the '--without-cuda-driver' behavior: including the GCC-shipped 'include/cuda/cuda.h' (not system <cuda.h>), and 'dlopen'ing the CUDA Driver library (not linking it). For development purposes, the libgomp nvptx plugin developer may still manually override that, to get the previous '--with-cuda-driver' behavior. libgomp/ * plugin/Makefrag.am: Evaluate 'if PLUGIN_NVPTX_DYNAMIC' to true. * plugin/configfrag.ac (--with-cuda-driver) (--with-cuda-driver-include, --with-cuda-driver-lib) (CUDA_DRIVER_INCLUDE, CUDA_DRIVER_LIB, PLUGIN_NVPTX_CPPFLAGS) (PLUGIN_NVPTX_LDFLAGS, PLUGIN_NVPTX_LIBS, PLUGIN_NVPTX_DYNAMIC): Remove. * testsuite/libgomp-test-support.exp.in (cuda_driver_include) (cuda_driver_lib): Remove. * testsuite/lib/libgomp.exp (libgomp_init): Don't consider these. * Makefile.in: Regenerate. * configure: Likewise. * testsuite/Makefile.in: Likewise. --- libgomp/Makefile.in | 50 +++--- libgomp/configure | 143 +----------------- libgomp/plugin/Makefrag.am | 25 ++- libgomp/plugin/configfrag.ac | 90 +---------- libgomp/testsuite/Makefile.in | 5 - libgomp/testsuite/lib/libgomp.exp | 13 -- libgomp/testsuite/libgomp-test-support.exp.in | 3 - 7 files changed, 37 insertions(+), 292 deletions(-) diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in index 2ac0397a036..8f6255f2d70 100644 --- a/libgomp/Makefile.in +++ b/libgomp/Makefile.in @@ -119,18 +119,8 @@ build_triplet = @build@ host_triplet = @host@ target_triplet = @target@ @PLUGIN_NVPTX_TRUE@am__append_1 = libgomp-plugin-nvptx.la - -# Including the GCC-shipped 'include/cuda/cuda.h' vs. system <cuda.h>. -@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__append_2 = -DPLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H \ -@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@ $(PLUGIN_NVPTX_CPPFLAGS) \ -@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@ -DPLUGIN_NVPTX_LINK_LIBCUDA - -# 'dlopen'ing the CUDA Driver library vs. linking it. -@PLUGIN_NVPTX_DYNAMIC_TRUE@@PLUGIN_NVPTX_TRUE@am__append_3 = $(DL_LIBS) -@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__append_4 = $(PLUGIN_NVPTX_LDFLAGS) -@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__append_5 = $(PLUGIN_NVPTX_LIBS) -@PLUGIN_GCN_TRUE@am__append_6 = libgomp-plugin-gcn.la -@USE_FORTRAN_TRUE@am__append_7 = openacc.f90 +@PLUGIN_GCN_TRUE@am__append_2 = libgomp-plugin-gcn.la +@USE_FORTRAN_TRUE@am__append_3 = openacc.f90 subdir = . ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \ @@ -207,10 +197,8 @@ libgomp_plugin_gcn_la_LINK = $(LIBTOOL) $(AM_V_lt) --tag=CC \ $(libgomp_plugin_gcn_la_LDFLAGS) $(LDFLAGS) -o $@ @PLUGIN_GCN_TRUE@am_libgomp_plugin_gcn_la_rpath = -rpath \ @PLUGIN_GCN_TRUE@ $(toolexeclibdir) -@PLUGIN_NVPTX_DYNAMIC_TRUE@@PLUGIN_NVPTX_TRUE@am__DEPENDENCIES_2 = $(am__DEPENDENCIES_1) -@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__DEPENDENCIES_3 = $(am__DEPENDENCIES_1) @PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_DEPENDENCIES = libgomp.la \ -@PLUGIN_NVPTX_TRUE@ $(am__DEPENDENCIES_2) $(am__DEPENDENCIES_3) +@PLUGIN_NVPTX_TRUE@ $(am__DEPENDENCIES_1) @PLUGIN_NVPTX_TRUE@am_libgomp_plugin_nvptx_la_OBJECTS = \ @PLUGIN_NVPTX_TRUE@ libgomp_plugin_nvptx_la-plugin-nvptx.lo libgomp_plugin_nvptx_la_OBJECTS = \ @@ -380,8 +368,6 @@ CFLAGS = @CFLAGS@ CPP = @CPP@ CPPFLAGS = @CPPFLAGS@ CPU_COUNT = @CPU_COUNT@ -CUDA_DRIVER_INCLUDE = @CUDA_DRIVER_INCLUDE@ -CUDA_DRIVER_LIB = @CUDA_DRIVER_LIB@ CYGPATH_W = @CYGPATH_W@ DEFS = @DEFS@ DEPDIR = @DEPDIR@ @@ -443,9 +429,6 @@ PACKAGE_URL = @PACKAGE_URL@ PACKAGE_VERSION = @PACKAGE_VERSION@ PATH_SEPARATOR = @PATH_SEPARATOR@ PERL = @PERL@ -PLUGIN_NVPTX_CPPFLAGS = @PLUGIN_NVPTX_CPPFLAGS@ -PLUGIN_NVPTX_LDFLAGS = @PLUGIN_NVPTX_LDFLAGS@ -PLUGIN_NVPTX_LIBS = @PLUGIN_NVPTX_LIBS@ RANLIB = @RANLIB@ SECTION_LDFLAGS = @SECTION_LDFLAGS@ SED = @SED@ @@ -538,7 +521,7 @@ libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include AM_CPPFLAGS = $(addprefix -I, $(search_path)) AM_CFLAGS = $(XCFLAGS) AM_LDFLAGS = $(XLDFLAGS) $(SECTION_LDFLAGS) $(OPT_LDFLAGS) -toolexeclib_LTLIBRARIES = libgomp.la $(am__append_1) $(am__append_6) +toolexeclib_LTLIBRARIES = libgomp.la $(am__append_1) $(am__append_2) nodist_toolexeclib_HEADERS = libgomp.spec # -Wc is only a libtool option. @@ -565,19 +548,30 @@ libgomp_la_SOURCES = alloc.c atomic.c barrier.c critical.c env.c \ oacc-parallel.c oacc-host.c oacc-init.c oacc-mem.c \ oacc-async.c oacc-plugin.c oacc-cuda.c priority_queue.c \ affinity-fmt.c teams.c allocator.c oacc-profiling.c \ - oacc-target.c $(am__append_7) + oacc-target.c $(am__append_3) # Nvidia PTX OpenACC plugin. @PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_version_info = -version-info $(libtool_VERSION) @PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_SOURCES = plugin/plugin-nvptx.c -@PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_CPPFLAGS = $(AM_CPPFLAGS) \ -@PLUGIN_NVPTX_TRUE@ $(am__append_2) -@PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_LDFLAGS = \ -@PLUGIN_NVPTX_TRUE@ $(libgomp_plugin_nvptx_version_info) \ -@PLUGIN_NVPTX_TRUE@ $(lt_host_flags) $(am__append_4) +@PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_CPPFLAGS = $(AM_CPPFLAGS) +@PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_LDFLAGS = $(libgomp_plugin_nvptx_version_info) \ +@PLUGIN_NVPTX_TRUE@ $(lt_host_flags) + + +# libgomp nvptx plugin developer's section. +# +# Including the GCC-shipped 'include/cuda/cuda.h' (default) vs. system <cuda.h>: +#libgomp_plugin_nvptx_la_CPPFLAGS += -DPLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H +#libgomp_plugin_nvptx_la_CPPFLAGS += -I[CUDA]/include +# +# 'dlopen'ing the CUDA Driver library (default): @PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_LIBADD = libgomp.la \ -@PLUGIN_NVPTX_TRUE@ $(am__append_3) $(am__append_5) +@PLUGIN_NVPTX_TRUE@ $(DL_LIBS) @PLUGIN_NVPTX_TRUE@libgomp_plugin_nvptx_la_LIBTOOLFLAGS = --tag=disable-static +# ... vs. linking it: +#libgomp_plugin_nvptx_la_CPPFLAGS += -DPLUGIN_NVPTX_LINK_LIBCUDA +#libgomp_plugin_nvptx_la_LDFLAGS += -L[CUDA]/lib64/stubs +#libgomp_plugin_nvptx_la_LIBADD += -lcuda # AMD GCN plugin @PLUGIN_GCN_TRUE@libgomp_plugin_gcn_version_info = -version-info $(libtool_VERSION) diff --git a/libgomp/configure b/libgomp/configure index 66dface222e..89f14e441f2 100755 --- a/libgomp/configure +++ b/libgomp/configure @@ -667,19 +667,12 @@ OPT_LDFLAGS SECTION_LDFLAGS PLUGIN_GCN_FALSE PLUGIN_GCN_TRUE -PLUGIN_NVPTX_DYNAMIC_FALSE -PLUGIN_NVPTX_DYNAMIC_TRUE PLUGIN_NVPTX_FALSE PLUGIN_NVPTX_TRUE offload_additional_lib_paths offload_additional_options offload_targets offload_plugins -PLUGIN_NVPTX_LIBS -PLUGIN_NVPTX_LDFLAGS -PLUGIN_NVPTX_CPPFLAGS -CUDA_DRIVER_LIB -CUDA_DRIVER_INCLUDE DL_LIBS libtool_VERSION ac_ct_FC @@ -829,9 +822,6 @@ enable_fast_install with_gnu_ld enable_libtool_lock enable_maintainer_mode -with_cuda_driver -with_cuda_driver_include -with_cuda_driver_lib enable_linux_futex enable_tls enable_symvers @@ -1504,16 +1494,6 @@ Optional Packages: --with-pic try to use only PIC/non-PIC objects [default=use both] --with-gnu-ld assume the C compiler uses GNU ld [default=no] - --with-cuda-driver=PATH specify prefix directory for installed CUDA driver - package. Equivalent to - --with-cuda-driver-include=PATH/include plus - --with-cuda-driver-lib=PATH/lib - --with-cuda-driver-include=PATH - specify directory for installed CUDA driver include - files - --with-cuda-driver-lib=PATH - specify directory for the installed CUDA driver - library --with-gcc-major-version-only use only GCC major number in filesystem paths @@ -11414,7 +11394,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 11417 "configure" +#line 11397 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -11520,7 +11500,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 11523 "configure" +#line 11503 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -15158,67 +15138,8 @@ done -# Look for the CUDA driver package. -CUDA_DRIVER_INCLUDE= -CUDA_DRIVER_LIB= - - -CUDA_DRIVER_CPPFLAGS= -CUDA_DRIVER_LDFLAGS= - -# Check whether --with-cuda-driver was given. -if test "${with_cuda_driver+set}" = set; then : - withval=$with_cuda_driver; -fi - - -# Check whether --with-cuda-driver-include was given. -if test "${with_cuda_driver_include+set}" = set; then : - withval=$with_cuda_driver_include; -fi - - -# Check whether --with-cuda-driver-lib was given. -if test "${with_cuda_driver_lib+set}" = set; then : - withval=$with_cuda_driver_lib; -fi - -case "x$with_cuda_driver" in - x) ;; - xno) - CUDA_DRIVER_INCLUDE=no - CUDA_DRIVER_LIB=no - ;; - *) CUDA_DRIVER_INCLUDE=$with_cuda_driver/include - CUDA_DRIVER_LIB=$with_cuda_driver/lib - ;; -esac -if test "x$with_cuda_driver_include" != x; then - CUDA_DRIVER_INCLUDE=$with_cuda_driver_include -fi -if test "x$with_cuda_driver_lib" != x; then - CUDA_DRIVER_LIB=$with_cuda_driver_lib -fi -if test "x$CUDA_DRIVER_INCLUDE" != x \ - && test "x$CUDA_DRIVER_INCLUDE" != xno; then - CUDA_DRIVER_CPPFLAGS=-I$CUDA_DRIVER_INCLUDE -fi -if test "x$CUDA_DRIVER_LIB" != x \ - && test "x$CUDA_DRIVER_LIB" != xno; then - CUDA_DRIVER_LDFLAGS=-L$CUDA_DRIVER_LIB -fi - PLUGIN_NVPTX=0 -PLUGIN_NVPTX_CPPFLAGS= -PLUGIN_NVPTX_LDFLAGS= -PLUGIN_NVPTX_LIBS= -PLUGIN_NVPTX_DYNAMIC=0 - - - - PLUGIN_GCN=0 - # Parse '--enable-offload-targets', figure out the corresponding libgomp # plugins, and configure to find the corresponding offload compilers. # 'offload_plugins' and 'offload_targets' will be populated in the same order. @@ -15250,53 +15171,7 @@ if test x"$enable_offload_targets" != x; then ;; *) tgt_plugin=nvptx - PLUGIN_NVPTX=$tgt - if test "x$CUDA_DRIVER_LIB" != xno \ - && test "x$CUDA_DRIVER_LIB" != xno; then - PLUGIN_NVPTX_CPPFLAGS=$CUDA_DRIVER_CPPFLAGS - PLUGIN_NVPTX_LDFLAGS=$CUDA_DRIVER_LDFLAGS - PLUGIN_NVPTX_LIBS='-lcuda' - - PLUGIN_NVPTX_save_CPPFLAGS=$CPPFLAGS - CPPFLAGS="$PLUGIN_NVPTX_CPPFLAGS $CPPFLAGS" - PLUGIN_NVPTX_save_LDFLAGS=$LDFLAGS - LDFLAGS="$PLUGIN_NVPTX_LDFLAGS $LDFLAGS" - PLUGIN_NVPTX_save_LIBS=$LIBS - LIBS="$PLUGIN_NVPTX_LIBS $LIBS" - cat confdefs.h - <<_ACEOF >conftest.$ac_ext -/* end confdefs.h. */ -#include "cuda.h" -int -main () -{ -CUresult r = cuCtxPushCurrent (NULL); - ; - return 0; -} -_ACEOF -if ac_fn_c_try_link "$LINENO"; then : - PLUGIN_NVPTX=1 -fi -rm -f core conftest.err conftest.$ac_objext \ - conftest$ac_exeext conftest.$ac_ext - CPPFLAGS=$PLUGIN_NVPTX_save_CPPFLAGS - LDFLAGS=$PLUGIN_NVPTX_save_LDFLAGS - LIBS=$PLUGIN_NVPTX_save_LIBS - fi - case $PLUGIN_NVPTX in - nvptx*) - if (test "x$CUDA_DRIVER_INCLUDE" = x \ - || test "x$CUDA_DRIVER_INCLUDE" = xno) \ - && (test "x$CUDA_DRIVER_LIB" = x \ - || test "x$CUDA_DRIVER_LIB" = xno); then - PLUGIN_NVPTX=1 - PLUGIN_NVPTX_DYNAMIC=1 - else - PLUGIN_NVPTX=0 - as_fn_error $? "CUDA driver package required for nvptx support" "$LINENO" 5 - fi - ;; - esac + PLUGIN_NVPTX=1 ;; esac ;; @@ -15362,14 +15237,6 @@ else PLUGIN_NVPTX_FALSE= fi - if test $PLUGIN_NVPTX_DYNAMIC = 1; then - PLUGIN_NVPTX_DYNAMIC_TRUE= - PLUGIN_NVPTX_DYNAMIC_FALSE='#' -else - PLUGIN_NVPTX_DYNAMIC_TRUE='#' - PLUGIN_NVPTX_DYNAMIC_FALSE= -fi - if test $PLUGIN_GCN = 1; then PLUGIN_GCN_TRUE= PLUGIN_GCN_FALSE='#' @@ -17137,10 +17004,6 @@ if test -z "${PLUGIN_NVPTX_TRUE}" && test -z "${PLUGIN_NVPTX_FALSE}"; then as_fn_error $? "conditional \"PLUGIN_NVPTX\" was never defined. Usually this means the macro was only invoked conditionally." "$LINENO" 5 fi -if test -z "${PLUGIN_NVPTX_DYNAMIC_TRUE}" && test -z "${PLUGIN_NVPTX_DYNAMIC_FALSE}"; then - as_fn_error $? "conditional \"PLUGIN_NVPTX_DYNAMIC\" was never defined. -Usually this means the macro was only invoked conditionally." "$LINENO" 5 -fi if test -z "${PLUGIN_GCN_TRUE}" && test -z "${PLUGIN_GCN_FALSE}"; then as_fn_error $? "conditional \"PLUGIN_GCN\" was never defined. Usually this means the macro was only invoked conditionally." "$LINENO" 5 diff --git a/libgomp/plugin/Makefrag.am b/libgomp/plugin/Makefrag.am index 66c8c12c1a6..5aad9ab5d8b 100644 --- a/libgomp/plugin/Makefrag.am +++ b/libgomp/plugin/Makefrag.am @@ -39,21 +39,18 @@ libgomp_plugin_nvptx_la_LDFLAGS = $(libgomp_plugin_nvptx_version_info) \ libgomp_plugin_nvptx_la_LIBADD = libgomp.la libgomp_plugin_nvptx_la_LIBTOOLFLAGS = --tag=disable-static -# Including the GCC-shipped 'include/cuda/cuda.h' vs. system <cuda.h>. -if PLUGIN_NVPTX_DYNAMIC -else -libgomp_plugin_nvptx_la_CPPFLAGS += -DPLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H -libgomp_plugin_nvptx_la_CPPFLAGS += $(PLUGIN_NVPTX_CPPFLAGS) -endif - -# 'dlopen'ing the CUDA Driver library vs. linking it. -if PLUGIN_NVPTX_DYNAMIC +# libgomp nvptx plugin developer's section. +# +# Including the GCC-shipped 'include/cuda/cuda.h' (default) vs. system <cuda.h>: +#libgomp_plugin_nvptx_la_CPPFLAGS += -DPLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H +#libgomp_plugin_nvptx_la_CPPFLAGS += -I[CUDA]/include +# +# 'dlopen'ing the CUDA Driver library (default): libgomp_plugin_nvptx_la_LIBADD += $(DL_LIBS) -else -libgomp_plugin_nvptx_la_CPPFLAGS += -DPLUGIN_NVPTX_LINK_LIBCUDA -libgomp_plugin_nvptx_la_LDFLAGS += $(PLUGIN_NVPTX_LDFLAGS) -libgomp_plugin_nvptx_la_LIBADD += $(PLUGIN_NVPTX_LIBS) -endif +# ... vs. linking it: +#libgomp_plugin_nvptx_la_CPPFLAGS += -DPLUGIN_NVPTX_LINK_LIBCUDA +#libgomp_plugin_nvptx_la_LDFLAGS += -L[CUDA]/lib64/stubs +#libgomp_plugin_nvptx_la_LIBADD += -lcuda endif if PLUGIN_GCN diff --git a/libgomp/plugin/configfrag.ac b/libgomp/plugin/configfrag.ac index 14203048bdb..ab03f94adac 100644 --- a/libgomp/plugin/configfrag.ac +++ b/libgomp/plugin/configfrag.ac @@ -40,60 +40,8 @@ AC_CHECK_HEADERS_ONCE(unistd.h) AC_CHECK_FUNCS_ONCE(secure_getenv __secure_getenv getuid geteuid getgid getegid) -# Look for the CUDA driver package. -CUDA_DRIVER_INCLUDE= -CUDA_DRIVER_LIB= -AC_SUBST(CUDA_DRIVER_INCLUDE) -AC_SUBST(CUDA_DRIVER_LIB) -CUDA_DRIVER_CPPFLAGS= -CUDA_DRIVER_LDFLAGS= -AC_ARG_WITH(cuda-driver, - [AS_HELP_STRING([--with-cuda-driver=PATH], - [specify prefix directory for installed CUDA driver package. - Equivalent to --with-cuda-driver-include=PATH/include - plus --with-cuda-driver-lib=PATH/lib])]) -AC_ARG_WITH(cuda-driver-include, - [AS_HELP_STRING([--with-cuda-driver-include=PATH], - [specify directory for installed CUDA driver include files])]) -AC_ARG_WITH(cuda-driver-lib, - [AS_HELP_STRING([--with-cuda-driver-lib=PATH], - [specify directory for the installed CUDA driver library])]) -case "x$with_cuda_driver" in - x) ;; - xno) - CUDA_DRIVER_INCLUDE=no - CUDA_DRIVER_LIB=no - ;; - *) CUDA_DRIVER_INCLUDE=$with_cuda_driver/include - CUDA_DRIVER_LIB=$with_cuda_driver/lib - ;; -esac -if test "x$with_cuda_driver_include" != x; then - CUDA_DRIVER_INCLUDE=$with_cuda_driver_include -fi -if test "x$with_cuda_driver_lib" != x; then - CUDA_DRIVER_LIB=$with_cuda_driver_lib -fi -if test "x$CUDA_DRIVER_INCLUDE" != x \ - && test "x$CUDA_DRIVER_INCLUDE" != xno; then - CUDA_DRIVER_CPPFLAGS=-I$CUDA_DRIVER_INCLUDE -fi -if test "x$CUDA_DRIVER_LIB" != x \ - && test "x$CUDA_DRIVER_LIB" != xno; then - CUDA_DRIVER_LDFLAGS=-L$CUDA_DRIVER_LIB -fi - PLUGIN_NVPTX=0 -PLUGIN_NVPTX_CPPFLAGS= -PLUGIN_NVPTX_LDFLAGS= -PLUGIN_NVPTX_LIBS= -PLUGIN_NVPTX_DYNAMIC=0 -AC_SUBST(PLUGIN_NVPTX_CPPFLAGS) -AC_SUBST(PLUGIN_NVPTX_LDFLAGS) -AC_SUBST(PLUGIN_NVPTX_LIBS) - PLUGIN_GCN=0 - # Parse '--enable-offload-targets', figure out the corresponding libgomp # plugins, and configure to find the corresponding offload compilers. # 'offload_plugins' and 'offload_targets' will be populated in the same order. @@ -125,42 +73,7 @@ if test x"$enable_offload_targets" != x; then ;; *) tgt_plugin=nvptx - PLUGIN_NVPTX=$tgt - if test "x$CUDA_DRIVER_LIB" != xno \ - && test "x$CUDA_DRIVER_LIB" != xno; then - PLUGIN_NVPTX_CPPFLAGS=$CUDA_DRIVER_CPPFLAGS - PLUGIN_NVPTX_LDFLAGS=$CUDA_DRIVER_LDFLAGS - PLUGIN_NVPTX_LIBS='-lcuda' - - PLUGIN_NVPTX_save_CPPFLAGS=$CPPFLAGS - CPPFLAGS="$PLUGIN_NVPTX_CPPFLAGS $CPPFLAGS" - PLUGIN_NVPTX_save_LDFLAGS=$LDFLAGS - LDFLAGS="$PLUGIN_NVPTX_LDFLAGS $LDFLAGS" - PLUGIN_NVPTX_save_LIBS=$LIBS - LIBS="$PLUGIN_NVPTX_LIBS $LIBS" - AC_LINK_IFELSE( - [AC_LANG_PROGRAM( - [#include "cuda.h"], - [CUresult r = cuCtxPushCurrent (NULL);])], - [PLUGIN_NVPTX=1]) - CPPFLAGS=$PLUGIN_NVPTX_save_CPPFLAGS - LDFLAGS=$PLUGIN_NVPTX_save_LDFLAGS - LIBS=$PLUGIN_NVPTX_save_LIBS - fi - case $PLUGIN_NVPTX in - nvptx*) - if (test "x$CUDA_DRIVER_INCLUDE" = x \ - || test "x$CUDA_DRIVER_INCLUDE" = xno) \ - && (test "x$CUDA_DRIVER_LIB" = x \ - || test "x$CUDA_DRIVER_LIB" = xno); then - PLUGIN_NVPTX=1 - PLUGIN_NVPTX_DYNAMIC=1 - else - PLUGIN_NVPTX=0 - AC_MSG_ERROR([CUDA driver package required for nvptx support]) - fi - ;; - esac + PLUGIN_NVPTX=1 ;; esac ;; @@ -216,5 +129,4 @@ fi AC_DEFINE_UNQUOTED(OFFLOAD_PLUGINS, "$offload_plugins", [Define to offload plugins, separated by commas.]) AM_CONDITIONAL([PLUGIN_NVPTX], [test $PLUGIN_NVPTX = 1]) -AM_CONDITIONAL([PLUGIN_NVPTX_DYNAMIC], [test $PLUGIN_NVPTX_DYNAMIC = 1]) AM_CONDITIONAL([PLUGIN_GCN], [test $PLUGIN_GCN = 1]) diff --git a/libgomp/testsuite/Makefile.in b/libgomp/testsuite/Makefile.in index 048844f0a40..7a88f0fe5c6 100644 --- a/libgomp/testsuite/Makefile.in +++ b/libgomp/testsuite/Makefile.in @@ -147,8 +147,6 @@ CFLAGS = @CFLAGS@ CPP = @CPP@ CPPFLAGS = @CPPFLAGS@ CPU_COUNT = @CPU_COUNT@ -CUDA_DRIVER_INCLUDE = @CUDA_DRIVER_INCLUDE@ -CUDA_DRIVER_LIB = @CUDA_DRIVER_LIB@ CYGPATH_W = @CYGPATH_W@ DEFS = @DEFS@ DEPDIR = @DEPDIR@ @@ -210,9 +208,6 @@ PACKAGE_URL = @PACKAGE_URL@ PACKAGE_VERSION = @PACKAGE_VERSION@ PATH_SEPARATOR = @PATH_SEPARATOR@ PERL = @PERL@ -PLUGIN_NVPTX_CPPFLAGS = @PLUGIN_NVPTX_CPPFLAGS@ -PLUGIN_NVPTX_LDFLAGS = @PLUGIN_NVPTX_LDFLAGS@ -PLUGIN_NVPTX_LIBS = @PLUGIN_NVPTX_LIBS@ RANLIB = @RANLIB@ SECTION_LDFLAGS = @SECTION_LDFLAGS@ SED = @SED@ diff --git a/libgomp/testsuite/lib/libgomp.exp b/libgomp/testsuite/lib/libgomp.exp index 0aaa58f19c5..11c90766704 100644 --- a/libgomp/testsuite/lib/libgomp.exp +++ b/libgomp/testsuite/lib/libgomp.exp @@ -189,19 +189,6 @@ proc libgomp_init { args } { append always_ld_library_path ":${atomic_library_path}" } } - global cuda_driver_include - global cuda_driver_lib - if { $cuda_driver_include != "" } { - # Stop gfortran from freaking out: - # Warning: Nonexistent include directory "[...]" - if {[file exists $cuda_driver_include]} { - lappend ALWAYS_CFLAGS "additional_flags=-I$cuda_driver_include" - } - } - if { $cuda_driver_lib != "" } { - lappend ALWAYS_CFLAGS "additional_flags=-L$cuda_driver_lib" - append always_ld_library_path ":$cuda_driver_lib" - } } # We use atomic operations in the testcases to validate results. diff --git a/libgomp/testsuite/libgomp-test-support.exp.in b/libgomp/testsuite/libgomp-test-support.exp.in index 3c88d1d5a62..36615b353aa 100644 --- a/libgomp/testsuite/libgomp-test-support.exp.in +++ b/libgomp/testsuite/libgomp-test-support.exp.in @@ -1,5 +1,2 @@ -set cuda_driver_include "@CUDA_DRIVER_INCLUDE@" -set cuda_driver_lib "@CUDA_DRIVER_LIB@" - set offload_plugins "@offload_plugins@" set offload_targets "@offload_targets@" -- 2.35.1 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-05-27 11:57 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-03-03 12:27 [wwwdocs][patch] gcc-12/changes.html: Document -misa update for nvptx Tobias Burnus 2022-03-30 12:27 ` [wwwdocs][patch] gcc-12: Nvptx updates Tom de Vries 2022-04-05 15:14 ` Proposal to remove '--with-cuda-driver' (was: [wwwdocs][patch] gcc-12: Nvptx updates) Thomas Schwinge 2022-04-05 18:46 ` Roger Sayle 2022-04-29 13:55 ` Proposal to remove '--with-cuda-driver' Thomas Schwinge 2022-04-06 9:57 ` Proposal to remove '--with-cuda-driver' (was: [wwwdocs][patch] gcc-12: Nvptx updates) Tom de Vries 2022-04-29 13:48 ` Proposal to remove '--with-cuda-driver' Thomas Schwinge 2022-05-13 12:29 ` libgomp nvptx plugin: Remove '--with-cuda-driver=[...]' etc. configuration option (was: Proposal to remove '--with-cuda-driver') Thomas Schwinge 2022-05-27 11:57 ` [PING] " Thomas Schwinge
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).