public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <rdsandiford@googlemail.com>
To: "Steve Ellcey " <sellcey@mips.com>
Cc: <law@redhat.com>,  <gcc@gcc.gnu.org>
Subject: Re: MIPS GCC test failure: gcc.dg/tree-ssa/ssa-dom-thread-4.c
Date: Sat, 01 Feb 2014 11:52:00 -0000	[thread overview]
Message-ID: <87iosz9hjh.fsf@talisman.default> (raw)
In-Reply-To: <5c24a8c6-2af6-4098-a64c-4760751aeef0@BAMAIL02.ba.imgtec.org>	(Steve Ellcey's message of "Fri, 31 Jan 2014 16:31:13 -0800")

"Steve Ellcey " <sellcey@mips.com> writes:
> I was looking at the test failure of gcc.dg/tree-ssa/ssa-dom-thread-4.c
> on MIPS.  The failure is in the scan of how many jumps are threaded
> which has changed from 6 to 4 on MIPS.

Yeah, I'd been leaving this one until I could devote a bit of time to it.

> I tracked down the change to this patch:
>
> 2013-11-19  Jeff Law  <law@redhat.com>
>
>         * tree-ssa-threadedge.c (thread_across_edge): After threading
>         through a joiner, allow threading a normal block requiring
>         duplication.
>
>         * tree-ssa-threadupdate.c (thread_block_1): Improve code to detect
>         jump threading requests that would muck up the loop structures.
>
>         * tree-ssa-threadupdate.c: Fix trailing whitespace.
>         * tree-ssa-threadupdate.h: Likewise.

Thanks for tracking down the patch that changed it.

> Now my initial thought is to just change the mips scan to look for
> 4 'Threaded' lines instead of 6 and be done with it, but the test has
> a long explanation of why 6 is the right answer on MIPS and I don't know
> what to do with this.  Even after looking at the new and old dom1 dump
> files I can't really explain why 4 is the right number now instead of 6.

It's because the earlier vrp1 pass is now doing the !kill_elt ->
continuation point threading (the third item from the list).
vrp1 runs before the header of the inner while loop is duplicated,
so here the transformation only happens once rather than twice.

vrp1 is now also duplicating the b_elt-testing block in:

      if (b_elt && kill_elt && kill_elt->indx == b_elt->indx
          ...

for the "kill_elt->indx >= b_elt->indx" branch of the while loop
so that it can thread out the known-true kill_elt test.  I.e.,
if the while loop stops on "kill_elt->indx >= b_elt->indx",
the if statement will test:

      if (b_elt && kill_elt->indx == b_elt->indx
          ...

But it's still down to dom1 to recognise that the b_elt test itself is
also redundant in this case, so the fourth item on the list still holds.

I applied this patch to update the MIPS results after checking
that it also works for arc-elf and avr-elf.

Thanks,
Richard


gcc/testsuite/
	* gcc.dg/tree-ssa/ssa-dom-thread-4.c: Adjust expected MIPS output.

Index: gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c
===================================================================
--- gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c	2014-02-01 11:37:12.793270725 +0000
+++ gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c	2014-02-01 11:37:13.021272556 +0000
@@ -66,7 +66,7 @@ bitmap_ior_and_compl (bitmap dst, const_
    "a_elt || b_elt" and "b_elt && kill_elt" into two conditions each,
    rather than using "(var1 != 0) op (var2 != 0)".  Also, as on other targets,
    we duplicate the header of the inner "while" loop.  There are then
-   6 threading opportunities:
+   4 threading opportunities:
 
    1x "!a_elt && b_elt" in the outer "while" loop
       -> the start of the inner "while" loop,
@@ -74,16 +74,13 @@ bitmap_ior_and_compl (bitmap dst, const_
    1x "!b_elt" in the first condition
       -> the outer "while" loop's continuation point,
 	 skipping the known-false "b_elt" in the second condition.
-   2x "!kill_elt" in the inner "while" loop
-      -> the outer "while" loop's continuation point,
-	 skipping the known-false "b_elt && kill_elt" in the second condition
-   2x "kill_elt->indx < b_elt->indx" in the first "while" loop
+   2x "kill_elt->indx >= b_elt->indx" in the first "while" loop
       -> "kill_elt->indx == b_elt->indx" in the second condition,
 	 skipping the known-true "b_elt && kill_elt" in the second
 	 condition.  */
 /* Likewise for arc.  */
 /* For avr, BRANCH_COST is by default 0, so the default
    LOGICAL_OP_NON_SHORT_CIRCUIT definition also computes as 0.  */
-/* { dg-final { scan-tree-dump-times "Threaded" 6 "dom1" { target mips*-*-* avr-*-* arc*-*-* } } } */
+/* { dg-final { scan-tree-dump-times "Threaded" 4 "dom1" { target mips*-*-* avr-*-* arc*-*-* } } } */
 /* { dg-final { cleanup-tree-dump "dom1" } } */
 

      reply	other threads:[~2014-02-01 11:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-01  0:32 Steve Ellcey 
2014-02-01 11:52 ` Richard Sandiford [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=87iosz9hjh.fsf@talisman.default \
    --to=rdsandiford@googlemail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=sellcey@mips.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).