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 <seg...@kernel.crashing.org> > Sent: Thursday, September 10, 2020 5:23 AM > To: Qian, Jianhua/钱 建华 <qia...@cn.fujitsu.com>; gcc@gcc.gnu.org; > richard.sandif...@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 >
