public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Jambor <mjambor@suse.cz>
To: Cesar Philippidis <cesar@codesourcery.com>,
	"gcc-patches\@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [patch,openacc] Fix PR71959: lto dump of callee counts
Date: Tue, 25 Sep 2018 13:01:00 -0000	[thread overview]
Message-ID: <ri6in2thgwp.fsf@suse.cz> (raw)
In-Reply-To: <319b3ebd-c601-449b-718c-963b68414224@codesourcery.com>

Hi,

I have noticed a few things...

On Thu, Sep 20 2018, Cesar Philippidis wrote:
> This is another old gomp4 patch that demotes an ICE in PR71959 to a
> linker warning. One problem here is that it is not clear if OpenACC
> allows individual member functions in C++ classes to be marked as acc
> routines. There's another issue accessing member data inside offloaded
> regions. We'll add some support for member data OpenACC 2.6, but some of
> the OpenACC C++ semantics are still unclear.
>
> Is this OK for trunk? I bootstrapped and regtested it for x86_64 Linux
> with nvptx offloading.
>
> Thanks,
> Cesar
> [PR71959] lto dump of callee counts
>
> 2018-XX-YY  Nathan Sidwell  <nathan@acm.org>
> 	    Cesar Philippidis  <cesar@codesourcery.com>
>
> 	gcc/
> 	* ipa-inline-analysis.c (inline_write_summary): Only dump callee
> 	counts when dumping the function's body.

...the changelog needs updating and....

>
> 	libgomp/
> 	* testsuite/libgomp.oacc-c++/pr71959.C: New.
> 	* testsuite/libgomp.oacc-c++/pr71959-a.C: New.
>
> (cherry picked from gomp-4_0-branch r239788)
> ---
>  gcc/ipa-fnsummary.c                           | 18 ++++++++---
>  .../testsuite/libgomp.oacc-c++/pr71959-a.C    | 31 +++++++++++++++++++
>  libgomp/testsuite/libgomp.oacc-c++/pr71959.C  | 31 +++++++++++++++++++
>  3 files changed, 75 insertions(+), 5 deletions(-)
>  create mode 100644 libgomp/testsuite/libgomp.oacc-c++/pr71959-a.C
>  create mode 100644 libgomp/testsuite/libgomp.oacc-c++/pr71959.C
>
> diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c
> index 62095c6cf6f..e796b085e14 100644
> --- a/gcc/ipa-fnsummary.c
> +++ b/gcc/ipa-fnsummary.c
> @@ -3409,8 +3409,10 @@ ipa_fn_summary_write (void)
>  	  int i;
>  	  size_time_entry *e;
>  	  struct condition *c;
> +	  int index = lto_symtab_encoder_encode (encoder, cnode);
> +	  bool body = encoder->nodes[index].body;
>  
> -	  streamer_write_uhwi (ob, lto_symtab_encoder_encode (encoder, cnode));
> +	  streamer_write_uhwi (ob, index);
>  	  streamer_write_hwi (ob, info->estimated_self_stack_size);
>  	  streamer_write_hwi (ob, info->self_size);
>  	  info->time.stream_out (ob);
> @@ -3453,10 +3455,16 @@ ipa_fn_summary_write (void)
>  	    info->array_index->stream_out (ob);
>  	  else
>  	    streamer_write_uhwi (ob, 0);
> -	  for (edge = cnode->callees; edge; edge = edge->next_callee)
> -	    write_ipa_call_summary (ob, edge);
> -	  for (edge = cnode->indirect_calls; edge; edge = edge->next_callee)
> -	    write_ipa_call_summary (ob, edge);
> +	  if (body)
> +	    {
> +	      /* Only write callee counts when we're emitting the
> +		 body, as the reader only knows about the callees when
> +		 the body's emitted.  */

this comment is wrong because write_ipa_call_summary does not only
stream counts but also sizes, predicates and other stuff.

I also wonder 1) whether the cnode->definition test that guards this
streaming should not be replaced by your body check (and why the
definition is not enough, really) and 2) why you don't have the same
problem with ipa_prop_write_jump_functions and the function it calls.

Martin

> +	      for (edge = cnode->callees; edge; edge = edge->next_callee)
> +		write_ipa_call_summary (ob, edge);
> +	      for (edge = cnode->indirect_calls; edge; edge = edge->next_callee)
> +		write_ipa_call_summary (ob, edge);
> +	    }
>  	}
>      }
>    streamer_write_char_stream (ob->main_stream, 0);

  reply	other threads:[~2018-09-25 12:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-20 18:06 Cesar Philippidis
2018-09-25 13:01 ` Martin Jambor [this message]
2018-12-21  3:45   ` Julian Brown
2018-12-21 13:29     ` Julian Brown
2018-12-21 13:32       ` Jakub Jelinek
2018-12-21 17:09         ` Julian Brown
2018-12-22 18:53           ` Iain Sandoe
2019-01-08 13:31             ` Julian Brown
2019-01-08 13:36               ` 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=ri6in2thgwp.fsf@suse.cz \
    --to=mjambor@suse.cz \
    --cc=cesar@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    /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).