public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Richard Biener <rguenther@suse.de>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Properly valueize values we value-number to
Date: Mon, 23 Feb 2015 22:44:00 -0000	[thread overview]
Message-ID: <54EBA55B.2050209@redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1502171459140.27763@zhemvz.fhfr.qr>

On 02/17/15 07:03, Richard Biener wrote:
>
> This is something I noticed some time ago and that I remembered when
> you added that looping SSA_NAME_VALUE to simplify_control_stmt_condition.
> Currently DOM doesn't make sure that when setting
> SSA_NAME_VALUE (x) = y that SSA_NAME_VALUE (y) == y, thus you could
> get SSA_NAME_VALUE forming a chain until you reach the final value.
>
> Thus the following patch which fixes all occurances and removes the
> looping from simplify_control_stmt_condition.  Did you have any
> testcase when you added that looping?
pr61607, which probably looks familiar :-)





>
> Note that this is purely by code inspection and I don't have any
> testcase where a SSA_NAME_VALUE chain causes missed optimizations
> (you'd have to disable a lot of other optimizations before dom1
> to be able to create a reasonably simple one).
>
> Anyway - the tree-ssa-dom.c part bootstrapped and tested ok on
> x86_64-unknown-linux-gnu, the tree-ssa-threadedge.c part bootstrapped
> ok ontop of that and testing is still in progress.
>
> Ok?
>
> Thanks,
> Richard.
>
> 2015-02-17  Richard Biener  <rguenther@suse.de>
>
> 	* tree-ssa-dom.c (record_equivalences_from_phis): Valueize PHI arg.
> 	(record_const_or_copy_1): Valueize y.
> 	(record_equivalences_from_stmt): Valueize rhs.
> 	* tree-ssa-threadedge.c (simplify_control_stmt_condition):
> 	Remove repeated valueization.
Given the regression was fixed elsewhere, let's table this until gcc-6.

I want to rip out large hunks of this code, at least on the threading 
side and replace it with a backwards walk similar to what Sebastian did 
for the FSM optimization.  As a nice side effect, that ought to 
completely disentangle DOM and the threader.

At the same time I want to see what effect we'd have by disabling these 
context sensitive propagations in DOM.  They add a lot of hair and I'm 
just not sure they're worth it.  If we really need them, perhaps we can 
get away with something simpler, outside of DOM.

jeff

      parent reply	other threads:[~2015-02-23 22:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-17 14:03 Richard Biener
2015-02-17 14:58 ` Richard Biener
2015-04-24 19:34   ` Jeff Law
2015-04-27  8:32     ` Richard Biener
2015-04-27 12:47       ` Richard Biener
2015-04-27 16:24         ` Jeff Law
2015-04-27 18:29           ` Richard Biener
2015-04-27 18:47             ` Jeff Law
2015-02-23 22:44 ` Jeff Law [this message]

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=54EBA55B.2050209@redhat.com \
    --to=law@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --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).