public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Tom de Vries <Tom_deVries@mentor.com>
Cc: Jan Hubicka <hubicka@ucw.cz>, Richard Biener <rguenther@suse.de>,
	Jakub Jelinek <jakub@redhat.com>,
	"gcc-patches@gnu.org" <gcc-patches@gnu.org>
Subject: Re: [PING][PATCH, PR67709 ] Don't call call_cgraph_insertion_hooks in simd_clone_create
Date: Tue, 16 Feb 2016 02:22:00 -0000	[thread overview]
Message-ID: <20160216022231.GA79627@kam.mff.cuni.cz> (raw)
In-Reply-To: <56C19C7F.1070202@mentor.com>

> On 08/02/16 13:54, Jakub Jelinek wrote:
> >On Mon, Feb 08, 2016 at 01:46:44PM +0100, Tom de Vries wrote:
> >>[ The pass before pass_omp_simd_clone is pass_dispatcher_calls. It has a
> >>function create_target_clone, similar to simd_clone_create, with a
> >>node.defition and !node.defition part. The !node.defition part does not call
> >>'symtab->call_cgraph_insertion_hooks (new_node)'. ]
> >
> >I'll defer to Honza or Richi if it is ok not to call cgraph insertion hooks
> >at this point (and since when they can be avoided), or what else should be
> >done.
> >
> >The patch could be ok even for 6.0, not just stage1, if they are ok with it
> >(or propose some other change).
> >
> 
> Ping (Given that Jakub suggested this or an alternative patch might
> be included in 6.0 stage4).
> 
> Original submission at
> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00543.html .

OK, so the ICE is that you intorduce new deifnition but you set in_other_partition
and do not really introudce gimple body for it?
In that case we should indeed not call creation hooks, because these are used only
when new function is introduced to a given partition.

Patch looks OK to me thus.
Honza.
> 
> Thanks,
> - Tom
> 
> >>Don't call call_cgraph_insertion_hooks in simd_clone_create
> >>
> >>2016-02-08  Tom de Vries  <tom@codesourcery.com>
> >>
> >>	PR lto/67709
> >>	* omp-low.c (simd_clone_create): Remove call to
> >>	symtab->call_cgraph_insertion_hooks.
> >>
> >>	* testsuite/libgomp.fortran/declare-simd-4.f90: New test.
> >
> >	Jakub
> >

  reply	other threads:[~2016-02-16  2:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-08 12:47 [PATCH, " Tom de Vries
2016-02-08 12:55 ` Jakub Jelinek
2016-02-15  9:38   ` [PING][PATCH, " Tom de Vries
2016-02-16  2:22     ` Jan Hubicka [this message]
2016-02-16  9:57       ` Tom de Vries
2016-02-16 10:04         ` Jakub Jelinek
2016-02-16 11:10           ` Tom de Vries
2016-02-16 11:12             ` Jakub Jelinek
2016-02-16 16:53               ` Tom de Vries
2016-02-16 16:55                 ` Jakub Jelinek
2016-02-16 20:52                   ` Tom de Vries

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=20160216022231.GA79627@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=Tom_deVries@mentor.com \
    --cc=gcc-patches@gnu.org \
    --cc=jakub@redhat.com \
    --cc=rguenther@suse.de \
    /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).