public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: "Qian, Jianhua" <qianjh@cn.fujitsu.com>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	richard.sandiford@arm.com
Subject: Re: A problem with one instruction multiple latencies and pipelines
Date: Wed, 9 Sep 2020 16:22:38 -0500	[thread overview]
Message-ID: <20200909212238.GE28786@gate.crashing.org> (raw)
In-Reply-To: <mptk0x5s5hw.fsf@arm.com>

Hi!

On Mon, Sep 07, 2020 at 09:20:59PM +0100, Richard Sandiford wrote:
> This is just personal opinion, but in general (from the point of view
> of a new port, or a new subport like SVE), I think the best approach
> to handling the "type" attribute is to start with the coarsest
> classification that makes sense, then split these relatively coarse
> types up whenever there's a specific need.

Agreed.

> When taking that approach, it's OK (and perhaps even a good sign)
> for an existing type to sometimes be too coarse for a new CPU.
> 
> So thanks for asking about this, and please don't feel constrained
> by the existing "type" classification.  IMO we should split existing
> types wherever that makes sense for new CPUs.

You can also use some other attributes to classify instructions, you
don't have to put it all in one "type" attribute.  This can of course be
done later, at a time when it is clearer what a good design will be.
Sometimes it is obvious from the start though :-)

(This primarily makes the pipeline descriptions much simpler, but also
custom scheduling code and the like.  If one core has two types of "A"
insn, say "Aa" and "Ab", it isn't nice if all other cores now have to
handle both "Aa" and "Ab" instead of just "A").


Segher

  parent reply	other threads:[~2020-09-09 21:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-07  6:08 Qian, Jianhua
2020-09-07  7:40 ` Richard Biener
2020-09-07  8:45   ` Qian, Jianhua
2020-09-07 11:58     ` Richard Biener
2020-09-07 20:20 ` Richard Sandiford
2020-09-08  5:34   ` Qian, Jianhua
2020-09-09 21:22   ` Segher Boessenkool [this message]
2020-09-10  5:01     ` Qian, Jianhua
2020-09-10 10:04     ` Richard Sandiford
2020-09-10 23:00       ` Segher Boessenkool
2020-09-11  7:44         ` Richard Sandiford
2020-09-11 13:58           ` Segher Boessenkool
2020-09-14  5:41             ` Qian, Jianhua
2020-09-14  9:55               ` Richard Sandiford
2020-09-14 18:41                 ` Segher Boessenkool
2020-09-14 19:35                   ` Richard Sandiford
2020-09-14 22:14                     ` Segher Boessenkool
2020-09-11 13:30 ` Richard Earnshaw
2020-09-14  2:53   ` Qian, Jianhua
2020-09-14  9:08     ` Richard Earnshaw

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=20200909212238.GE28786@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=gcc@gcc.gnu.org \
    --cc=qianjh@cn.fujitsu.com \
    --cc=richard.sandiford@arm.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).