public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kito Cheng <kito.cheng@gmail.com>
To: Sandra Loosemore <sandra@codesourcery.com>
Cc: Jeff Law <law@redhat.com>, Eric Botcazou <ebotcazou@adacore.com>,
		"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	Chung-Lin Tang <cltang@codesourcery.com>,
		Marcus Shawcroft <Marcus.Shawcroft@arm.com>,
	Richard Earnshaw <Richard.Earnshaw@arm.com>,
		"Schmidt, Bernd - Code Sourcery" <bernds@codesourcery.com>
Subject: Re: [patch] fix regrename pass to ensure renamings produce valid insns
Date: Tue, 30 Jun 2015 03:54:00 -0000	[thread overview]
Message-ID: <CA+yXCZBiSOs8AxOAs93K65kvJBpewUjiYmy5UtcSAawB1Suzmg@mail.gmail.com> (raw)
In-Reply-To: <5590624E.8090409@codesourcery.com>

Hi all:

This patch seem will broken when disable assert checking for c6x....

Index: gcc/config/c6x/c6x.c
===================================================================
--- gcc/config/c6x/c6x.c (revision 225104)
+++ gcc/config/c6x/c6x.c (working copy)
@@ -3516,7 +3516,7 @@ try_rename_operands (rtx_insn *head, rtx
   best_reg =
     find_rename_reg (this_head, super_class, &unavailable, old_reg, true);

-  regrename_do_replace (this_head, best_reg);
+  gcc_assert (regrename_do_replace (this_head, best_reg));

   count_unit_reqs (new_reqs, head, PREV_INSN (tail));
   merge_unit_reqs (new_reqs);
@@ -3529,7 +3529,7 @@ try_rename_operands (rtx_insn *head, rtx
        unit_req_imbalance (reqs), unit_req_imbalance (new_reqs));
     }
   if (unit_req_imbalance (new_reqs) > unit_req_imbalance (reqs))
-    regrename_do_replace (this_head, old_reg);
+    gcc_assert (regrename_do_replace (this_head, old_reg));
   else
     memcpy (reqs, new_reqs, sizeof (unit_req_table));


On Mon, Jun 29, 2015 at 5:08 AM, Sandra Loosemore
<sandra@codesourcery.com> wrote:
> On 06/24/2015 09:46 PM, Jeff Law wrote:
>>
>> On 06/23/2015 07:00 PM, Sandra Loosemore wrote:
>>>
>>> On 06/18/2015 11:32 AM, Eric Botcazou wrote:
>>>>>
>>>>> The attached patch teaches regrename to validate insns affected by each
>>>>> register renaming before making the change.  I can see at least two
>>>>> other ways to handle this -- earlier, by rejecting renamings that
>>>>> result
>>>>> in invalid instructions when it's searching for the best renaming; or
>>>>> later, by validating the entire set of renamings as a group instead of
>>>>> incrementally for each one -- but doing it all in regname_do_replace
>>>>> seems least disruptive and risky in terms of the existing code.
>>>>
>>>>
>>>> OK, but the patch looks incomplete, rename_chains should be adjusted
>>>> as well,
>>>> i.e. regrename_do_replace should now return a boolean.
>>>
>>>
>>> Like this?  I tested this on nios2 and x86_64-linux-gnu, as before, plus
>>> built for aarch64-linux-gnu and ran the gcc testsuite.
>>>
>>> The c6x back end also calls regrename_do_replace.  I am not set up to
>>> build or test on that target, and Bernd told me off-list that it would
>>> never fail on that target anyway so I have left that code alone.
>>>
>>> -Sandra
>>>
>>> regrename-2.log
>>>
>>>
>>> 2015-06-23  Chung-Lin Tang<cltang@codesourcery.com>
>>>         Sandra Loosemore<sandra@codesourcery.com>
>>>
>>>     gcc/
>>>     * regrename.h (regrename_do_replace): Change to return bool.
>>>     * regrename.c (rename_chains): Check return value of
>>>     regname_do_replace.
>>>     (regrename_do_replace): Re-validate the modified insns and
>>>     return bool status.
>>>     * config/aarch64/cortex-a57-fma-steering.c (rename_single_chain):
>>>     Update to match rename_chains changes.
>>
>> As Eric mentioned, please put an assert to verify that the call from the
>> c6x backend never fails.
>>
>> The regrename and ARM bits are fine.
>>
>> Do you have a testcase that you can add to the suite?  If so it'd be
>> appreciated if you could include that too.
>>
>> Approved with the c6x assert if a testcase isn't available or
>> exceedingly difficult to produce.
>
>
> Thanks.  I've committed the attached version.
>
> Re the testcase, this fixed 16 FAILs on existing tests in the gcc testsuite
> with the forthcoming nios2 load/store multiple instruction support, all
> assembler errors due to the bad instructions being generated.  There's
> nothing I can do on nios2 for a testcase until I get those patches committed
> (I'm still trying to re-test and tidy them up for submission), plus I think
> the failures are rather fragile -- depending on the register allocator
> choosing an initial register numbering that allows peephole optimizers to
> trigger, etc.  But, I will revisit this later and see what I can do.
>
> -Sandra
>

  reply	other threads:[~2015-06-30  3:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-17 17:36 Sandra Loosemore
2015-06-17 19:23 ` Richard Sandiford
2015-06-18 18:26 ` Eric Botcazou
2015-06-24  3:31   ` Sandra Loosemore
2015-06-24  7:59     ` Ramana Radhakrishnan
2015-06-24 14:57       ` Sandra Loosemore
2015-06-24 16:50     ` Eric Botcazou
2015-06-24 16:59       ` Eric Botcazou
2015-06-25  3:53     ` Jeff Law
2015-06-25 12:30       ` Bernd Schmidt
2015-06-25 13:54         ` Eric Botcazou
2015-06-25 13:59           ` Bernd Schmidt
2015-06-29  0:18       ` Sandra Loosemore
2015-06-30  3:54         ` Kito Cheng [this message]
2015-06-30  5:08           ` Sandra Loosemore
2015-06-30  5:26             ` Chung-Lin Tang
2015-06-30  6:11               ` Chung-Lin Tang
2015-06-30  9:08                 ` Eric Botcazou
2015-06-30 11:03                   ` Chung-Lin Tang
2015-06-30 19:11                   ` Sandra Loosemore
2015-06-30 21:31                     ` Eric Botcazou
2015-07-01 17:03         ` Jeff Law
2015-11-06 10:48 ` Bernd Schmidt
2015-11-06 19:51   ` Jeff Law
2015-11-13 15:13     ` Bernd Schmidt

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=CA+yXCZBiSOs8AxOAs93K65kvJBpewUjiYmy5UtcSAawB1Suzmg@mail.gmail.com \
    --to=kito.cheng@gmail.com \
    --cc=Marcus.Shawcroft@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=bernds@codesourcery.com \
    --cc=cltang@codesourcery.com \
    --cc=ebotcazou@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=sandra@codesourcery.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).