From: Zhongyunde <zhongyunde@huawei.com>
To: Richard Sandiford <richard.sandiford@arm.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
"Yangfei (Felix)" <felix.yang@huawei.com>
Subject: RE: RE: [PATCH PR95696] regrename creates overlapping register allocations for vliw
Date: Wed, 22 Jul 2020 14:58:39 +0000 [thread overview]
Message-ID: <3077AC2A5F43A1418280D802C4B7FC117371414E@dggemm508-mbx.china.huawei.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2871 bytes --]
> -----Original Message-----
> From: Richard Sandiford [mailto:richard.sandiford@arm.com]
> Sent: Wednesday, July 22, 2020 12:12 AM
> To: Zhongyunde <zhongyunde@huawei.com>
> Cc: gcc-patches@gcc.gnu.org; Yangfei (A) <lancelo.yang@huawei.com>
> Subject: Re: 答复: [PATCH PR95696] regrename creates overlapping
> register allocations for vliw
>
> Zhongyunde <zhongyunde@huawei.com> writes:
> > Thanks for your review.
> >
> > First of all, this is an optimization.
>
> OK, good.
>
> > gcc do sms before reload, and here each insn use pseudo-register.
> After reload, they are allocated hard-register, then the regrename pass try
> to adjust the register number with def/use chain created by
> build_def_use.
> > As now gcc doesn't consider the VLIW bundles, so regrename pass may
> updated a reg which may not really unused, which will bring in invalid
> VLIW bundles.
> > Before the final schedule, we usually recheck the validation of VLIW
> bundles, and reschedule the conflicted insns into two VLIW to make them
> validation to avoid above issue, so this is not a correctness issue.
> > Certainly, reschedule the conflicted insns into two VLIW will destroy
> the kernel loop's sms schedule result, and usually it will be harmful to the
> performance.
>
> Yeah. The reason I was worried about the TI markers being stale is that, in
> general, register allocation can introduce new spills and reloads, can add
> and remove instructions, and can convert instructions into different forms
> (e.g. as a result of register elimination).
> There are then post-reload optimisers that can change the code further.
> All these things could invalidate the VLIW bundling done by the first
> scheduler.
>
> It sounds like that's not happening in your motivating testcase, and the
> VLIW bundling is still correct (for this loop) by the time that regrename
> runs. Is that right?
Yes, it is right.
> It's interesting that this is for a testcase using SMS. One of the traditional
> problems with the GCC implementation of SMS has been ensuring that
> later passes don't mess up the scheduled loop. So in your testcase, does
> register allocation succeed for the SMS loop without invalidating the
> bundling decisions?
Yes.
> If so, then it's probably better to avoid running regrename on it at all.
> It mostly exists to help the second scheduling pass, but the second
> scheduling pass shouldn't be messing with an SMS loop anyway. Also,
> although the patch deals with one case in which regrename could disrupt
> the bundling, there are others too.
>
> So maybe one option would be to make regrename ignore blocks that
> have BB_DISABLE_SCHEDULE set. (Sorry if that's been discussed and
> discounted
> already.)
ok, according your advice, I make a new patch attached.
> Thanks,
> Richard
[-- Attachment #2: PR95696_1.patch --]
[-- Type: application/octet-stream, Size: 2274 bytes --]
diff --git a/gcc/regrename.c b/gcc/regrename.c
index c38173a77..0ccc5e18c 100644
--- a/gcc/regrename.c
+++ b/gcc/regrename.c
@@ -284,6 +284,48 @@ create_new_chain (unsigned this_regno, unsigned this_nregs, rtx *loc,
return head;
}
+/* For the def-use chain HEAD of SMS block, find the registers with REG_UNUSED
+ conflict its VLIW constraint and set the corresponding bits in *PSET. */
+
+static void
+merge_vliw_overlapping_regs (HARD_REG_SET *pset, struct du_head *head)
+{
+ rtx_insn *insn;
+ rtx_insn *cur_insn = head->first->insn;
+ basic_block bb = BLOCK_FOR_INSN (cur_insn);
+
+ /* Just run regrename for no-SMS related basic block. */
+ if ((bb->flags & BB_DISABLE_SCHEDULE) == 0 || (bb->flags & BB_MODIFIED) != 0)
+ return;
+
+ /* SMS related basic block generate VLIW before reload, and avoid disrupting
+ the bundling if the new rename reg is valid for bundling. */
+ for (insn = prev_active_insn (cur_insn); insn && BLOCK_FOR_INSN (insn) == bb;
+ insn = prev_active_insn (insn))
+ {
+ rtx note;
+
+ for (note = REG_NOTES (insn); note; note = XEXP (note, 1))
+ {
+ if (REG_NOTE_KIND (note) == REG_UNUSED)
+ {
+ int regno = REGNO (XEXP (note, 0));
+ SET_HARD_REG_BIT (*pset, regno);
+ if (dump_file)
+ {
+ fprintf (dump_file, "Register %s may confilct with REG_UNUSED \
+ in insn %d\n",
+ reg_names[regno], INSN_UID (insn));
+ }
+ }
+ }
+
+ /* Walk until the first insn of current vliw. */
+ if (GET_MODE (insn) == TImode)
+ break;
+ }
+}
+
/* For a def-use chain HEAD, find which registers overlap its lifetime and
set the corresponding bits in *PSET. */
@@ -372,6 +414,9 @@ find_rename_reg (du_head_p this_head, enum reg_class super_class,
/* Mark registers that overlap this chain's lifetime as unavailable. */
merge_overlapping_regs (unavailable, this_head);
+ /* Mark registers that conflict vliw constraint as unavailable. */
+ merge_vliw_overlapping_regs (unavailable, this_head);
+
/* Compute preferred rename class of super union of all the classes
in the chain. */
preferred_class
next reply other threads:[~2020-07-22 14:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-22 14:58 Zhongyunde [this message]
2020-07-22 20:47 ` Richard Sandiford
2020-07-26 7:28 ` Zhongyunde
2020-07-27 4:53 ` Zhongyunde
2020-07-27 17:32 ` Richard Sandiford
2020-07-31 6:09 ` Zhongyunde
2020-07-31 9:32 ` Richard Sandiford
2020-08-03 7:40 ` Yangfei (Felix)
2020-08-03 14:05 ` Richard Sandiford
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=3077AC2A5F43A1418280D802C4B7FC117371414E@dggemm508-mbx.china.huawei.com \
--to=zhongyunde@huawei.com \
--cc=felix.yang@huawei.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=richard.sandiford@arm.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).