public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Kwok Cheung Yeung <kcy@codesourcery.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] openmp: Implicit 'declare target' for C++ static initializers
Date: Tue, 8 Dec 2020 17:24:37 +0100	[thread overview]
Message-ID: <20201208162437.GG3788@tucnak> (raw)
In-Reply-To: <fd3c7b40-6a39-afc0-7b97-37d0bf0003ad@codesourcery.com>

On Thu, Nov 19, 2020 at 06:07:28PM +0000, Kwok Cheung Yeung wrote:
> Even without this patch, G++ currently accepts something like

Sorry for the delay.

> int foo() { return 1; }
> int x = foo();
> #pragma omp declare target to(x)
> 
> but will not generate the device-side initializer for x, even though x is
> now present on the device. So this part of the implementation is broken with
> or without the patch.
> 
> Given that my patch doesn't make the current situation any worse, can I
> commit this portion of it to trunk for now, and leave device-side dynamic
> initialization for later?

Ok, but for the patch I have a few nits:

> +/* The C++ version of the get_decl_init langhook returns the static
> +   initializer for a variable declaration if present, otherwise it
> +   tries to find and return the dynamic initializer.  If not present,
> +   it returns NULL.  */
> +
> +static tree*
> +cxx_get_decl_init (tree decl)

The GCC coding style (appart from libstdc++) is type * rather than type*,
occurs several times in the patch.

> +{
> +  tree node;
> +
> +  if (DECL_INITIAL (decl))
> +    return &DECL_INITIAL (decl);
> +
> +  for (node = dynamic_initializers; node; node = TREE_CHAIN (node))
> +    if (TREE_VALUE (node) == decl)
> +      return &TREE_PURPOSE (node);

I'm worried with many dynamic initializers this will be worst case
quadratic.  Can't you use instead a hash map?  Note, as this is in the
FE, we might need to worry about PCH and GC.
Thus the hash map needs to be indexed by DECL_UIDs rather than pointers,
so perhaps use decl_tree_map?
Also, I'm worried that nothing releases dynamic_initializers (or the
decl_tree_map replacement).  We need it only during the discovery and not
afterwards, so it would be nice if the omp declare target discovery at the
end called another lang hook that would free the decl_tree_map, so that GC
can take it all.
If trees would remain there afterwards, we'd need to worry about destructive
gimplifier too and would need to unshare the dynamic initializers or
something.

I think it would be best to use omp_ in the hook name(s), and:
> --- a/gcc/cp/decl2.c
> +++ b/gcc/cp/decl2.c
> @@ -4940,6 +4940,11 @@ c_parse_final_cleanups (void)
>  	 loop.  */
>        vars = prune_vars_needing_no_initialization (&static_aggregates);
>  
> +      /* Copy the contents of VARS into DYNAMIC_INITIALIZERS.  */
> +      for (t = vars; t; t = TREE_CHAIN (t))
> +	dynamic_initializers = tree_cons (TREE_PURPOSE (t), TREE_VALUE (t),
> +					  dynamic_initializers);

Not to add there anything if (!flag_openmp).  We don't need to waste memory
when nobody is going to look at it.

	Jakub


  parent reply	other threads:[~2020-12-08 16:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-28 14:20 Kwok Cheung Yeung
2020-10-29 10:03 ` Jakub Jelinek
2020-11-19 18:07   ` Kwok Cheung Yeung
2020-11-27 21:55     ` PING " Kwok Cheung Yeung
2020-12-08 16:24     ` Jakub Jelinek [this message]
2020-12-18 15:10       ` Kwok Cheung Yeung
2020-12-18 15:47         ` Jakub Jelinek
2020-12-18 19:31         ` Jakub Jelinek
2020-12-18 20:15           ` Kwok Cheung Yeung
2020-12-18 20:21             ` Jakub Jelinek

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=20201208162437.GG3788@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=kcy@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).