public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Jeff Law <law@redhat.com>
Cc: Jan Hubicka <hubicka@ucw.cz>,
	James Greenhalgh <james.greenhalgh@arm.com>,
	Andrew Pinski <pinskia@gmail.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	nd@arm.com
Subject: Re: backward threading heuristics tweek
Date: Mon, 15 Aug 2016 20:06:00 -0000	[thread overview]
Message-ID: <20160815200609.GA26405@kam.mff.cuni.cz> (raw)
In-Reply-To: <d09ca941-22c6-fe75-11e1-e8e50ebfd1f0@redhat.com>

> >So the threaded path lives fully inside loop1: 6->8->9->3->4->6 propagating
> >that phi_inserted is 0 after the first iteration of the loop.  This looks like
> >useful loop peeling oppurtunity which does not garble loop structure. So
> >perhaps threading paths starting and passing loop latch (i.e. peeling) is
> >sane? Perhaps all paths fully captured in the loop in question are?
> Peeling like this has long been a point of contention -- it totally
> mucks things up like vectorizing.
> 
> The general issue that the threader knows nothing about the
> characteristics of the loop -- thus peeling is at this point is
> premature and just as likely to hinder performance as improve it.
> 
> I'm never been happy with how this aspect of threading vs loop opts
> turned out and we have open BZs related to this rats nest of issues.

Ok, then we perhaps just want to silence the testcase?

Honza
> 
> jeff
> 

  reply	other threads:[~2016-08-15 20:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-06 10:19 Jan Hubicka
2016-08-05 21:34 ` Jeff Law
2016-08-07 17:31 ` Andrew Pinski
2016-08-08  8:29   ` James Greenhalgh
2016-08-11 12:36     ` Jan Hubicka
2016-08-15 16:57       ` Jeff Law
2016-08-15 20:06         ` Jan Hubicka [this message]
2016-08-16 15:43           ` Jeff Law
2016-08-11 11:35   ` Jan Hubicka
2016-08-12 15:07     ` James Greenhalgh

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=20160815200609.GA26405@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=james.greenhalgh@arm.com \
    --cc=law@redhat.com \
    --cc=nd@arm.com \
    --cc=pinskia@gmail.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).