From: Thomas Schwinge <thomas@codesourcery.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: <gcc-patches@gcc.gnu.org>
Subject: Re: [committed] openmp: Add support for HBW or large capacity or interleaved memory through the libmemkind.so library
Date: Thu, 9 Jun 2022 12:11:28 +0200 [thread overview]
Message-ID: <87a6am5epb.fsf@euler.schwinge.homeip.net> (raw)
In-Reply-To: <YqGs96PqQhyxj0yV@tucnak>
Hi Jakub!
On 2022-06-09T10:19:03+0200, Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> This patch adds support for dlopening libmemkind.so
Instead of 'dlopen'ing literally 'libmemkind.so':
> --- libgomp/allocator.c.jj 2022-06-08 08:21:03.099446883 +0200
> +++ libgomp/allocator.c 2022-06-08 13:41:45.647133610 +0200
> + void *handle = dlopen ("libmemkind.so", RTLD_LAZY);
..., shouldn't this instead 'dlopen' 'libmemkind.so.0'? At least for
Debian/Ubuntu, the latter ('libmemkind.so.0') is shipped in the "library"
package:
$ apt-file list libmemkind0 | grep -F libmemkind.so
libmemkind0: /usr/lib/x86_64-linux-gnu/libmemkind.so.0
libmemkind0: /usr/lib/x86_64-linux-gnu/libmemkind.so.0.0.1
..., but the former ('libmemkind.so') only in the "development" package:
$ apt-file list libmemkind-dev | grep -F libmemkind.so
libmemkind-dev: /usr/lib/x86_64-linux-gnu/libmemkind.so
..., which users of GCC/libgomp shouldn't have to care about.
Any plans about test cases for this? (Not trivial, I suppose?)
Or, at least some 'gomp_debug' logging, what's happening behind the
scenes?
> --- libgomp/config/linux/allocator.c.jj 2022-06-08 08:58:23.197078191 +0200
> +++ libgomp/config/linux/allocator.c 2022-06-08 09:39:15.108410730 +0200
> @@ -0,0 +1,36 @@
> +#define _GNU_SOURCE
> +#include "libgomp.h"
> +#if defined(PLUGIN_SUPPORT) && defined(LIBGOMP_USE_PTHREADS)
> +#define LIBGOMP_USE_MEMKIND
> +#endif
> +
> +#include "../../../allocator.c"
Given this use of 'PLUGIN_SUPPORT' (and thus 'dlopen' etc.) for something
different than libgomp plugins (offloading), might move 'DL_LIBS',
'PLUGIN_SUPPORT' from 'libgomp/plugin/configfrag.ac' into
'libgomp/configure.ac', and 'libgomp_la_LIBADD += $(DL_LIBS)' from
'libgomp/plugin/Makefrag.am' into 'libgomp/Makefile.am'.
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
next prev parent reply other threads:[~2022-06-09 10:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-09 8:19 Jakub Jelinek
2022-06-09 10:11 ` Thomas Schwinge [this message]
2022-06-09 11:57 ` Jakub Jelinek
2022-06-10 19:23 ` Jakub Jelinek
2022-06-09 17:07 ` Richard Sandiford
2022-06-09 17:48 ` Jakub Jelinek
2022-06-28 21:29 ` Andrew Stubbs
2022-06-29 10:45 ` Jakub Jelinek
2022-06-29 12:24 ` Andrew Stubbs
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=87a6am5epb.fsf@euler.schwinge.homeip.net \
--to=thomas@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.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).