public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "crazylht at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/108707] suboptimal allocation with same memory op for many different instructions.
Date: Wed, 08 Feb 2023 03:15:05 +0000	[thread overview]
Message-ID: <bug-108707-4-g3AwaIWRzd@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-108707-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108707

Hongtao.liu <crazylht at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-* i?86-*-*

--- Comment #1 from Hongtao.liu <crazylht at gmail dot com> ---
It's related to memory_move_cost, in RA

1466  /* If this insn loads a parameter from its stack slot, then it
1467     represents a savings, rather than a cost, if the parameter is
1468     stored in memory.  Record this fact.
1469
1470     Similarly if we're loading other constants from memory (constant
1471     pool, TOC references, small data areas, etc) and this is the only
1472     assignment to the destination pseudo.
1473
1474     Don't do this if SET_SRC (set) isn't a general operand, if it is
1475     a memory requiring special instructions to load it, decreasing
1476     mem_cost might result in it being loaded using the specialized
1477     instruction into a register, then stored into stack and loaded
1478     again from the stack.  See PR52208.
1479
1480     Don't do this if SET_SRC (set) has side effect.  See PR56124.  */
1481  if (set != 0 && REG_P (SET_DEST (set)) && MEM_P (SET_SRC (set))
1482      && (note = find_reg_note (insn, REG_EQUIV, NULL_RTX)) != NULL_RTX
1483      && ((MEM_P (XEXP (note, 0))
1484           && !side_effects_p (SET_SRC (set)))
1485          || (CONSTANT_P (XEXP (note, 0))
1486              && targetm.legitimate_constant_p (GET_MODE (SET_DEST (set)),
1487                                                XEXP (note, 0))
1488              && REG_N_SETS (REGNO (SET_DEST (set))) == 1))
1489      && general_operand (SET_SRC (set), GET_MODE (SET_SRC (set)))
1490      /* LRA does not use equiv with a symbol for PIC code.  */
1491      && (! ira_use_lra_p || ! pic_offset_table_rtx
1492          || ! contains_symbol_ref_p (XEXP (note, 0))))
1493    {
1494      enum reg_class cl = GENERAL_REGS;
1495      rtx reg = SET_DEST (set);
1496      int num = COST_INDEX (REGNO (reg));
1497
1498      COSTS (costs, num)->mem_cost
1499        -= ira_memory_move_cost[GET_MODE (reg)][cl][1] * frequency;
1500      record_address_regs (GET_MODE (SET_SRC (set)),
1501                           MEM_ADDR_SPACE (SET_SRC (set)),
1502                           XEXP (SET_SRC (set), 0), 0, MEM, SCRATCH,
1503                           frequency * 2);
1504      counted_mem = true;

we use GENERAL_REGS for E_V16SFmode move cost which should be inaccurate, i
think when preferred regclass is unknown, we'd better use NO_REGS.

 588            /* Costs for NO_REGS are used in cost calculation on the
 589               1st pass when the preferred register classes are not
 590               known yet.  In this case we take the best scenario.  */

  reply	other threads:[~2023-02-08  3:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-08  3:11 [Bug rtl-optimization/108707] New: " crazylht at gmail dot com
2023-02-08  3:15 ` crazylht at gmail dot com [this message]
2023-02-09 13:38 ` [Bug rtl-optimization/108707] " rguenth at gcc dot gnu.org
2023-03-09  5:58 ` crazylht at gmail dot com
2023-03-09  5:59 ` crazylht at gmail dot com
2023-03-09  5:59 ` crazylht at gmail dot com
2023-03-09  6:00 ` crazylht at gmail dot com
2023-04-23  1:57 ` cvs-commit at gcc dot gnu.org
2023-11-01  5:29 ` crazylht at gmail dot com

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-108707-4-g3AwaIWRzd@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: 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).