public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/100328] IRA doesn't model matching constraint well Date: Thu, 24 Jun 2021 12:36:18 +0000 [thread overview] Message-ID: <bug-100328-4-eZjf3CG5xq@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-100328-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100328 Kewen Lin <linkw at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Last reconfirmed| |2021-06-24 Ever confirmed|0 |1 --- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> --- Created attachment 51059 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51059&action=edit ira-respect-matching-constraint-v2 This v2 considers the situation that: for one preferred register class there can be two or more alternatives, one of them has the matching constraint, while another doesn't have. For the given operand, even if it's assigned by a hardware reg which doesn't meet the matching constraint, it can simply use the alternative which doesn't have matching constraint so no register copy is needed. One typical case is define_insn *mov<mode>_internal2 on rs6000: (define_insn "*mov<mode>_internal2" [(set (match_operand:CC 2 "cc_reg_operand" "=y,x,?y") (compare:CC (match_operand:P 1 "gpc_reg_operand" "0,r,r") (const_int 0))) (set (match_operand:P 0 "gpc_reg_operand" "=r,r,r") (match_dup 1))] "" "@ cmp<wd>i %2,%0,0 mr. %0,%1 #" So we shouldn't create constraint copy for it. For fma style insns on rs6000, there are also several alternatives for preferred regclass and also only one with matching constraint. The difference is that for the given operand although there is no matching constraint applied for the alternaitve but matching constraint is being applied for one other input operand in this same alternative, it means when one matching constraint can be applied to more than one input operand, it has to have several alternatives like this. And to create constraint copies for all of these input operands with matching constraint is fine, once the matching constraint is honored on one input operand, it implicitly disable the others due to the interference relationship. So this patch is going to record and check all the other alternatives, which don't have matching constraint but with preferred classes, whether there is one input operand having same matching constraint. It also considers the possible free register move in the same register class, disable this if so since the register copy to meet the constraint is considered as free. I re-evaluated SPEC2017 performance with option set Ofast unroll, bmks 508.namd_r and 519.lbm_r were observed to be improved by 2.4% ~ 3.8% on Power8 and Power9. As mentioned before, it's bootstrapped/regtested on powerpc64le-linux-gnu P9 and x86_64-redhat-linux, but hit some regression failures on aarch64, I am still investigating the only one PASS->FAIL: (the others are XFAIL->XPASS) PASS->FAIL: gcc.target/aarch64/sve/acle/general/pr94683.c -march=armv8.2-a+sve -moverride=tune=none check-function-bodies test In this case, the newly created constraint copy is expected (which was shuffle copy), but this copy change somehow affects the full cost on register 92 due to conflict with reg 102. Need more digging on this.
next prev parent reply other threads:[~2021-06-24 12:36 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-29 6:41 [Bug rtl-optimization/100328] New: IRA doesn't model dup num " linkw at gcc dot gnu.org 2021-04-30 8:30 ` [Bug rtl-optimization/100328] " linkw at gcc dot gnu.org 2021-06-23 18:28 ` [Bug rtl-optimization/100328] IRA doesn't model matching " vmakarov at gcc dot gnu.org 2021-06-24 12:11 ` linkw at gcc dot gnu.org 2021-06-24 12:36 ` linkw at gcc dot gnu.org [this message] 2021-06-28 3:27 ` linkw at gcc dot gnu.org 2021-06-28 5:25 ` linkw at gcc dot gnu.org 2021-06-29 16:01 ` rsandifo at gcc dot gnu.org 2021-07-01 6:18 ` linkw at gcc dot gnu.org 2021-07-06 2:35 ` cvs-commit at gcc dot gnu.org 2021-07-06 2:35 ` cvs-commit at gcc dot gnu.org 2021-07-07 3:07 ` linkw at gcc dot gnu.org
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=bug-100328-4-eZjf3CG5xq@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /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: linkBe 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).