public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Tobias Burnus <tobias@codesourcery.com>
Cc: Jan Hubicka <jh@suse.cz>, gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [Patch] OpenMP: Handle cpp_implicit_alias in declare-target discovery (PR96390)
Date: Wed, 16 Sep 2020 12:36:47 +0200	[thread overview]
Message-ID: <20200916103647.GV21814@tucnak> (raw)
In-Reply-To: <ed402555-4430-c5ba-458d-111a59d5bf4e@codesourcery.com>

On Mon, Sep 14, 2020 at 03:25:29PM +0200, Tobias Burnus wrote:
> Updated version attached. Does it seem to make sense?

I think you want Honza on this primarily, I'm always lost in the cgraph
alias code.

> --- a/gcc/omp-offload.c
> +++ b/gcc/omp-offload.c
> @@ -196,21 +196,34 @@ omp_declare_target_var_p (tree decl)
>  static tree
>  omp_discover_declare_target_tgt_fn_r (tree *tp, int *walk_subtrees, void *data)
>  {
> -  if (TREE_CODE (*tp) == FUNCTION_DECL
> -      && !omp_declare_target_fn_p (*tp)
> -      && !lookup_attribute ("omp declare target host", DECL_ATTRIBUTES (*tp)))
> +  if (TREE_CODE (*tp) == FUNCTION_DECL)
>      {
> -      tree id = get_identifier ("omp declare target");
> -      if (!DECL_EXTERNAL (*tp) && DECL_SAVED_TREE (*tp))
> -	((vec<tree> *) data)->safe_push (*tp);
> -      DECL_ATTRIBUTES (*tp) = tree_cons (id, NULL_TREE, DECL_ATTRIBUTES (*tp));
> +      tree decl = *tp;
>        symtab_node *node = symtab_node::get (*tp);
>        if (node != NULL)
>  	{
> +	  while (node->alias_target)
> +	    node = symtab_node::get (node->alias_target);
> +	  node = node->ultimate_alias_target ();

I think the above is either you walk the aliases yourself, or use
ultimate_alias_target, but not both.  For the first one, e.g.
ultimate_alias_target_1 uses
      if (node->alias && node->analyzed)
        node = node->get_alias_target ();
in the loop.

And the second thing is, I'm not sure how the aliases behave if the
ultimate alias target is properly marked as omp declare target, but some
of the aliases are not.  The offloaded code will still call the alias,
so do we somehow arrange for the aliases to be also emitted into the
offloading LTO IL?
We don't really need to push the aliases into ((vec<tree> *) data),
that is only for function definitions (what will needs to be scanned for
further references), but I wonder if the aliases that are needed shouldn't
be marked node->offloadable and have "omp declare target" attribute added
for them too.

Perhaps use ultimate_alias_target (); first, handle the ultimate alias,
but keep the old node around, and if different from the ultimate alias,
do the node = node->get_alias_target () loop until you reach the ultimate
alias and for each add "omp declare target" and set node->offloadable
if not already there?

> +	  decl = node->decl;
> +	  if (omp_declare_target_fn_p (decl)
> +	      || lookup_attribute ("omp declare target host",
> +				   DECL_ATTRIBUTES (decl)))
> +	    return NULL_TREE;
> +
>  	  node->offloadable = 1;
>  	  if (ENABLE_OFFLOADING)
>  	    g->have_offload = true;
>  	}
> +      else if (omp_declare_target_fn_p (decl)
> +	       || lookup_attribute ("omp declare target host",
> +				    DECL_ATTRIBUTES (decl)))
> +	return NULL_TREE;
> +
> +      tree id = get_identifier ("omp declare target");
> +      if (!DECL_EXTERNAL (decl) && DECL_SAVED_TREE (decl))
> +	((vec<tree> *) data)->safe_push (decl);
> +      DECL_ATTRIBUTES (decl) = tree_cons (id, NULL_TREE, DECL_ATTRIBUTES (decl));
>      }
>    else if (TYPE_P (*tp))
>      *walk_subtrees = 0;

	Jakub


  reply	other threads:[~2020-09-16 10:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 15:37 Tobias Burnus
2020-08-17  7:17 ` *PING* – " Tobias Burnus
2020-08-25 16:58   ` *PING**2 " Tobias Burnus
2020-08-31 15:53 ` Jakub Jelinek
2020-09-14 13:25   ` Tobias Burnus
2020-09-16 10:36     ` Jakub Jelinek [this message]
2020-09-16 23:15       ` Tobias Burnus
2020-09-22  7:11         ` Tobias Burnus
2020-09-22  7:36           ` Jakub Jelinek
2020-09-22 14:11             ` Tobias Burnus
2020-09-22 14:24               ` Jakub Jelinek
2020-09-22 15:39                 ` Tobias Burnus
2020-09-23 13:52                   ` Tobias Burnus
2020-09-23 14:06                     ` Jakub Jelinek
2020-09-23 15:45                       ` Tobias Burnus
2020-09-25 11:23                         ` 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=20200916103647.GV21814@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jh@suse.cz \
    --cc=tobias@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).