public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jskumari at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/109009] Shrink Wrap missed opportunity
Date: Fri, 23 Jun 2023 15:03:51 +0000	[thread overview]
Message-ID: <bug-109009-4-7PMOjnSIV8@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-109009-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #8 from Surya Kumari Jangala <jskumari at gcc dot gnu.org> ---
(In reply to Surya Kumari Jangala from comment #7)
> There are a couple of issues in IRA:
> 
> 1. In improve_allocation() routine, we are not considering save/restore cost
> of using a callee save register (r31 in the failing case). Due to this, r31
> is being chosen instead of r3 for allocno r118.
> 

I made changes in the improve_allocation() routine to consider the save/restore
cost, but this still results in r31 being chosen for allocno r118.

Save/restore cost is computed by using the costs in the "ira_memory_move_cost"
array. But the memory move costs are quite small, it is 4. So even adding this
to r31 does not make the cost of r31 large enough for it to be not chosen.

However, while computing the save/restore cost, we are considering only the
memory move cost but not the BB frequency. I think it is important to consider
the frequency too. We factor in the frequency when we compute the savings on
removed copies in allocno_copy_cost_saving(). In this routine, we multiply the
frequency with ira_register_move_cost. So why not factor in the frequency for
memory move cost?

For the testcase we are considering:

BB2:
  set r123, r4
  set r122, r3
  set r120, compare(r123, 0)
  set r118, r122
  if r120 jump BB4 else jump BB3
BB3:
  call bar()
BB4:
  set r3, r118+1
  return r3

In improve_allocation(), we compute the cost improvement of each hard register
for allocno r118. And for each hard register we compute the
allocno_copy_cost_saving() if that hard reg is assigned to r118. In
allocno_copy_cost_saving(), we check if there are copies involving r118. And we
have one copy:
    set r118, r122

Since r122 is a copy of r3, so the copy cost saving if r3 is assigned to r118
is:
(freq of the copy insn) * ira_register_move_cost

Here, freq of the copy insn is taken as 1000 and ira_register_move_cost is 2.
So the copy cost saving is 2000. Note that BB2 in which the copy insn occurs is
the first BB.

The save insn for r31 will be placed in the prolog, so the freq of prolog needs
to be taken into consideration.

  parent reply	other threads:[~2023-06-23 15:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-03 14:04 [Bug rtl-optimization/109009] New: " jskumari at gcc dot gnu.org
2023-03-03 16:40 ` [Bug rtl-optimization/109009] " segher at gcc dot gnu.org
2023-03-05  5:23 ` jskumari at gcc dot gnu.org
2023-03-05 12:19 ` jskumari at gcc dot gnu.org
2023-03-05 15:01 ` segher at gcc dot gnu.org
2023-04-14 17:44 ` jskumari at gcc dot gnu.org
2023-05-10 11:51 ` jskumari at gcc dot gnu.org
2023-05-11  9:49 ` jskumari at gcc dot gnu.org
2023-06-23 15:03 ` jskumari at gcc dot gnu.org [this message]
2023-06-23 19:57 ` bergner at gcc dot gnu.org
2023-06-23 20:04 ` bergner at gcc dot gnu.org
2023-06-27 13:18 ` jskumari at gcc dot gnu.org
2023-06-27 13:19 ` jskumari 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-109009-4-7PMOjnSIV8@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).