public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Dimitrije Milosevic <Dimitrije.Milosevic@Syrmia.com>
To: Jeff Law <jeffreyalaw@gmail.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Cc: Djordje Todorovic <Djordje.Todorovic@syrmia.com>,
	"richard.guenther@gmail.com" <richard.guenther@gmail.com>
Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost complexity.
Date: Fri, 28 Oct 2022 06:43:37 +0000	[thread overview]
Message-ID: <AM0PR03MB4882D37AEAB5AFC0906FDEC682329@AM0PR03MB4882.eurprd03.prod.outlook.com> (raw)
In-Reply-To: <3c50de1f-c00b-9f8a-a604-a71bc546f1c2@gmail.com>

Hi Jeff,

> THe part I don't understand is, if you only have BASE+OFF, why does 
> preventing the calculation of more complex addressing modes matter?  ie, 
> what's the point of computing the cost of something like base + off + 
> scaled index when the target can't utilize it?

Well, the complexities of all addressing modes other than BASE + OFFSET are
equal to 0. For targets like Mips, which only has BASE + OFFSET, it would still
be more complex to use a candidate with BASE + INDEX << SCALE + OFFSET
than a candidate with BASE + INDEX, for example, as it has to compensate
the lack of other addressing modes somehow. If complexities for both of
those are equal to 0, in cases where complexities decide which candidate is
to be chosen, a more complex candidate may be picked.

Regards,
Dimitrije


From: Jeff Law <jeffreyalaw@gmail.com>
Sent: Friday, October 28, 2022 1:02 AM
To: Dimitrije Milosevic <Dimitrije.Milosevic@Syrmia.com>; gcc-patches@gcc.gnu.org <gcc-patches@gcc.gnu.org>
Cc: Djordje Todorovic <Djordje.Todorovic@syrmia.com>
Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost complexity. 
 

On 10/21/22 07:52, Dimitrije Milosevic wrote:
> From: Dimitrije Milošević <dimitrije.milosevic@syrmia.com>
>
> This patch reverts the computation of address cost complexity
> to the legacy one. After f9f69dd, complexity is calculated
> using the valid_mem_ref_p target hook. Architectures like
> Mips only allow BASE + OFFSET addressing modes, which in turn
> prevents the calculation of complexity for other addressing
> modes, resulting in non-optimal candidate selection.
>
> gcc/ChangeLog:
>
>        * tree-ssa-address.cc (multiplier_allowed_in_address_p): Change
>        to non-static.
>        * tree-ssa-address.h (multiplier_allowed_in_address_p): Declare.
>        * tree-ssa-loop-ivopts.cc (compute_symbol_and_var_present): Reintroduce.
>        (compute_min_and_max_offset): Likewise.
>        (get_address_cost): Revert
>        complexity calculation.

THe part I don't understand is, if you only have BASE+OFF, why does 
preventing the calculation of more complex addressing modes matter?  ie, 
what's the point of computing the cost of something like base + off + 
scaled index when the target can't utilize it?


jeff


  reply	other threads:[~2022-10-28  6:43 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-21 13:52 [PATCH 0/2] ivopts: Fix candidate selection for architectures with limited addressing modes Dimitrije Milosevic
2022-10-21 13:52 ` [PATCH 1/2] ivopts: Revert computation of address cost complexity Dimitrije Milosevic
2022-10-25 11:08   ` Richard Biener
2022-10-25 13:00     ` Dimitrije Milosevic
2022-10-27 23:02   ` Jeff Law
2022-10-28  6:43     ` Dimitrije Milosevic [this message]
2022-10-28  7:00       ` Richard Biener
2022-10-28 13:39         ` Dimitrije Milosevic
2022-11-01 18:46         ` Jeff Law
2022-11-02  8:40           ` Dimitrije Milosevic
2022-11-07 13:35             ` Richard Biener
2022-12-15 15:26               ` Dimitrije Milosevic
2022-12-16  9:58                 ` Richard Biener
2022-12-16 11:37                   ` Dimitrije Milosevic
2022-12-16 11:58                     ` Richard Biener
2022-10-21 13:52 ` [PATCH 2/2] ivopts: Consider number of invariants when calculating register pressure Dimitrije Milosevic
2022-10-25 11:07   ` Richard Biener
2022-10-25 13:00     ` Dimitrije Milosevic
2022-10-28  7:38       ` Richard Biener
2022-10-28 13:39         ` Dimitrije Milosevic
2022-11-07 12:56           ` Richard Biener
2024-03-18 11:28 [PATCH 1/2] ivopts: Revert computation of address cost complexity Aleksandar Rakic
2024-03-18 20:27 Aleksandar Rakic
2024-04-15 13:30 ` Aleksandar Rakic

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=AM0PR03MB4882D37AEAB5AFC0906FDEC682329@AM0PR03MB4882.eurprd03.prod.outlook.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).