From: Hans-Peter Nilsson <hp@bitrange.com>
To: Richard Sandiford <richard.sandiford@linaro.org>
Cc: gcc@gcc.gnu.org
Subject: Re: Just what are rtx costs?
Date: Thu, 18 Aug 2011 00:55:00 -0000 [thread overview]
Message-ID: <alpine.BSF.2.00.1108172028170.67029@dair.pair.com> (raw)
In-Reply-To: <m3aab8rsya.fsf@richards-thinkpad.stglab.manchester.uk.ibm.com>
On Wed, 17 Aug 2011, Richard Sandiford wrote:
> It also means
> that constants that are slightly more expensive than a register --
> somewhere in the range [0, COSTS_N_INSNS (1)] -- end up seeming
> cheaper than registers.
Yes, perhaps some scale factor has to be applied to get
reasonable cost granularity in an improved cost model for the
job... Some constants *are* more expensive (extra words and/or
extra cycles), yet preferable to registers for one (or maybe two
or...) insns. You don't want to find that all insns except
constant-loads suddenly use register arguments and no
port-specific metric way to tweak it. Mentioned for the record.
> By default, the cost of a SET is:
>
> COSTS_N_INSNS (1)
> + rtx_cost (SET_DEST (x), SET, speed)
> + rtx_cost (SET_SRC (x), SET, speed)
'k.
> But it seems like there's some double-counting for complex SET_SRCs here.
Bugs.
> As others have said, it would be nice if costs could
> be extracted from the .md file, but that's more work than I have time
> for now.
Yes, let's start by getting the semantics settled and
implemented first.
> Is it worth changing the costs anyway?
IMHO, it's worth making it consistent, linear, TRT...
> But that hardly seems clean either. Perhaps we should instead make
> the SET_SRC always include the cost of the SET, even for registers,
> constants and the like. Thoughts?
Seems more of maintaining a wart than an improvement for
consistency.
I don't think you can get into trouble for trying to improve
this area for consistency: between releases a port already
usually arbitrarily loses on some type of codes and costs have
to be re-tweaked, unless performance is closely tracked.
Aiming for traceability can only help (like, "read the added doc
blurb on how to define the port RTX costs instead of gdb
stepping and code inspection").
brgds, H-P
next prev parent reply other threads:[~2011-08-18 0:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-17 14:52 Richard Sandiford
2011-08-17 17:29 ` Georg-Johann Lay
2011-08-19 12:25 ` Richard Sandiford
2011-08-21 17:03 ` Georg-Johann Lay
2011-08-22 8:20 ` Richard Sandiford
2011-08-22 9:59 ` Richard Guenther
2011-08-22 13:08 ` Joern Rennecke
2011-08-22 15:53 ` David Edelsohn
2011-08-22 12:12 ` Georg-Johann Lay
2011-08-22 23:23 ` Peter Bigot
2011-08-26 14:41 ` Georg-Johann Lay
2011-08-17 18:56 ` Paolo Bonzini
2011-08-18 7:58 ` Richard Sandiford
2011-08-18 0:55 ` Hans-Peter Nilsson [this message]
2011-08-18 8:14 ` Richard Sandiford
2011-08-19 14:17 ` Richard Sandiford
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=alpine.BSF.2.00.1108172028170.67029@dair.pair.com \
--to=hp@bitrange.com \
--cc=gcc@gcc.gnu.org \
--cc=richard.sandiford@linaro.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).