A problem with one instruction multiple latencies and pipelines

[Qian, Jianhua]

Hi Segher

> 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 :-)

Thank you for your advice. It is also a good idea.
Considering other cores(existing and future),
I think it is better to keep the type attribute unchanging,
and add other attributes to classify instructions.

Regards
Qian

> -----Original Message-----
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Sent: Thursday, September 10, 2020 5:23 AM
> To: Qian, Jianhua/钱 建华 <qianjh@cn.fujitsu.com>; gcc@gcc.gnu.org;
> richard.sandiford@arm.com
> Subject: Re: A problem with one instruction multiple latencies and pipelines
> 
> 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
>