public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Dimitrije Milošević" <dimitrije.milosevic@syrmia.com>
To: gcc-patches@gcc.gnu.org
Cc: djordje.todorovic@syrmia.com, richard.guenther@gmail.com,
	jeffreyalaw@gmail.com
Subject: [PATCH 0/2]: Fix address cost complexity and register pressure cost calculation.
Date: Wed, 21 Dec 2022 14:12:12 +0100	[thread overview]
Message-ID: <20221221131214.190579-1-dimitrije.milosevic@syrmia.com> (raw)

Architectures like Mips are very limited when it comes to addressing modes. Therefore, the expected
behavior would be that, for the BASE + OFFSET addressing mode, complexity is lower, while, for more
complex addressing modes (e.g. BASE + INDEX << SCALE), which are not supported, complexity is
higher. Currently, the complexity calculation algorithm bails out if BASE + INDEX addressing mode
is not supported by the target architecture, resuling in 0-complexities for all candidates, which
leads to non-optimal candidate selection, especially in scenarios where there are multiple nested
loops.

Register pressure cost model isn't optimal for the case when there are enough registers. Currently,
the register pressure cost is bumped up by another n_cands, while there is no reason for the
register pressure cost to be equal to n_cands + n_invs (for that case).
Adding another n_cands could be used as a tie-breaker for the two cases where we do have enough
registers and the sum of n_invs and n_cands is equal, however I think there are two problems with
that:
  - How often does it happen that we have two cases where we do have enough registers,
  n_invs + n_cands sums are equal, and n_cands differ? I think that's pretty rare.
  - Bumping up the cost by another n_cands may lead to cost for the "If we do have
  enough registers." case to be higher than for other cases, which doesn't make sense.

Dimitrije Milosevic (2):
  ivopts: ivopts: Compute complexity for unsupported addressing modes.
  ivopts: Revert register pressure cost when there are enough registers.

 gcc/tree-ssa-loop-ivopts.cc | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)
---
2.25.1



             reply	other threads:[~2022-12-21 13:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-21 13:12 Dimitrije Milošević [this message]
2022-12-21 13:12 ` [PATCH 1/2] ivopts: Compute complexity for unsupported addressing modes Dimitrije Milošević
2022-12-21 13:12 ` [PATCH 2/2] ivopts: Revert register pressure cost when there are enough registers Dimitrije Milošević
2023-05-15 10:44   ` Richard Biener
2023-05-15 12:23     ` Richard Biener
2023-05-15 14:32       ` Jovan Dmitrovic

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=20221221131214.190579-1-dimitrije.milosevic@syrmia.com \
    --to=dimitrije.milosevic@syrmia.com \
    --cc=djordje.todorovic@syrmia.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=richard.guenther@gmail.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).