public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Bernd Schmidt <bschmidt@redhat.com>
Cc: Thomas Schwinge <thomas@codesourcery.com>,
	gcc-patches@gcc.gnu.org,
	       Nathan Sidwell <nathan@codesourcery.com>,
	       Joseph Myers <joseph@codesourcery.com>
Subject: Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)
Date: Tue, 20 Oct 2015 12:13:00 -0000	[thread overview]
Message-ID: <20151020121308.GC478@tucnak.redhat.com> (raw)
In-Reply-To: <56262961.90101@redhat.com>

On Tue, Oct 20, 2015 at 01:45:37PM +0200, Bernd Schmidt wrote:
> Both of you can ignore me if you feel I'm not making sense, but what exactly
> is the use case for -foffload=disable? Isn't it slightly redundant with
> -fno-openacc? IMO it's not an option that alters the available devices,
> that's a question that is answered at run-time and doesn't (or shouldn't)
> really depend on compiler switches. As a user I'd expect -foffload=disable
> to just prevent generation of offloaded code for the things I'm compiling.
> As Jakub pointed out, shared libraries may still contain other pieces that
> are offloadable.
> 
> I guess I don't fully understand why you want to go to great lengths to
> disable devices at run-time based on a compile-time switch. What's the
> reasoning here?

At least for OpenMP, I'm also happy with what we do now (except for the
ability to configure offloading targets as optional, i.e. dynamically
configure the default based on what packages user install rather than
just on how it has been configured, so that e.g. just because it has been
configured for PTX offloading the host GCC itself doesn't have to have a
dependency on the proprietary CUDA stuff in any way).
I believe in OpenMP nobody says that if the device HW is available, but user
chose to not compile offloading code/variables for that particular device
that it can't show up among omp_get_num_devices ().  And I think it is
entirely fine if say target data map succeeds to that device, but then
target is offloaded, if that is caused by users configure or command line
choice.  Maybe OpenACC has different requirements, is it required to
terminate the program if it can't fulfill the requested offloading?

In any case, I'm fine with something I've noted in the last mail, or with
the status quo, but not with running constructors in TUs or even shared
libraries just because they have been compiled with -fopenmp (and either
haven't used any OpenMP code at all, or just the non-*target* directives).

	Jakub

  reply	other threads:[~2015-10-20 12:13 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-27 20:58 Pass -foffload targets from driver to libgomp at link time Joseph Myers
2015-09-03 14:58 ` Ping " Joseph Myers
2015-09-10 14:01   ` Ping^2 " Joseph Myers
2015-09-10 14:03     ` Bernd Schmidt
2015-09-11 14:29       ` Joseph Myers
2015-09-11 14:48         ` Bernd Schmidt
2015-09-11 15:28           ` Joseph Myers
2015-09-11 15:47             ` Jakub Jelinek
2015-09-11 16:16               ` Joseph Myers
2015-09-28 10:09               ` Thomas Schwinge
2015-09-29  9:48                 ` Jakub Jelinek
2015-09-30 16:15                   ` Thomas Schwinge
2015-10-19 16:56                     ` Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time) Thomas Schwinge
2015-10-20 10:03                       ` Jakub Jelinek
2015-10-20 10:44                         ` Bernd Schmidt
2015-10-20 11:18                         ` Thomas Schwinge
2015-10-20 11:49                           ` Bernd Schmidt
2015-10-20 12:13                             ` Jakub Jelinek [this message]
2015-10-20 11:52                           ` Jakub Jelinek
  -- strict thread matches above, loose matches on Subject: below --
2014-09-27 18:17 [PATCH 2/n] OpenMP 4.0 offloading infrastructure: LTO streaming Ilya Verbin
2014-09-29  1:10 ` Jan Hubicka
2014-09-29 17:37   ` Ilya Verbin
2014-09-30 11:40     ` Thomas Schwinge
2014-10-01 16:13       ` Ilya Verbin
2014-10-08  8:45         ` Jakub Jelinek
2014-10-08  9:13           ` Jakub Jelinek
2014-10-15 14:28         ` Richard Biener
2014-10-20 11:21           ` Ilya Verbin
2014-10-20 11:26             ` Jakub Jelinek
2014-10-24 14:16             ` Ilya Verbin
2014-10-24 14:29               ` Jakub Jelinek
2014-10-28 19:32                 ` Ilya Verbin
2014-11-03  9:24                   ` Jakub Jelinek
2014-11-05 12:47                     ` Ilya Verbin
2014-11-05 12:50                       ` Jakub Jelinek
2014-11-07 14:41                         ` Kirill Yukhin
2014-11-12  9:32                       ` Richard Biener
2014-11-12 14:11                         ` Kirill Yukhin
2014-11-12 14:23                           ` Richard Biener
2014-11-12 14:35                             ` Kirill Yukhin
2014-11-12 14:41                               ` Richard Biener
2014-11-12 17:38                                 ` Ilya Verbin
2014-11-13  8:51                                   ` Richard Biener
2015-07-31 15:37                       ` Thomas Schwinge
2015-07-31 15:43                         ` Ilya Verbin
2015-08-05  8:40                           ` Richard Biener
2015-08-05 15:09                             ` Ilya Verbin
2015-08-14  9:49                               ` Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time) (was: [PATCH 2/n] OpenMP 4.0 offloading infrastructure: LTO streaming) Thomas Schwinge
2015-08-14 13:29                                 ` Ilya Verbin
2015-08-17 13:57                                   ` Martin Jambor
2015-08-14 17:08                                 ` Joseph Myers
2015-08-14 21:48                                   ` Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time) Thomas Schwinge
2015-08-15  4:03                                     ` Joseph Myers
2015-08-18 16:55                                       ` Thomas Schwinge
2015-08-20 23:38                                         ` Joseph Myers
2015-08-21 16:13                                           ` Nathan Sidwell
2015-08-21 16:21                                             ` Joseph Myers
2015-08-24 18:05                                               ` Joseph Myers
2015-08-24 22:50                                                 ` Joseph Myers
2015-08-24 23:26                                                   ` Nathan Sidwell
2015-08-25 15:04                                           ` Joseph Myers
2018-05-20 20:30                                           ` [og7] " Thomas Schwinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151020121308.GC478@tucnak.redhat.com \
    --to=jakub@redhat.com \
    --cc=bschmidt@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=nathan@codesourcery.com \
    --cc=thomas@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).