OK, thanks :)
On Thu, Apr 20, 2023 at 12:35 PM Jeff Law <j...@ventanamicro.com> wrote: > > This is primarily Raphael's work. All I did was adjust it to apply to > the trunk and add the new types to generic.md's scheduling model. > > > The basic idea here is to make sure we have the ability to schedule the > bitmanip instructions with a finer degree of control. Some of the > bitmanip instructions are likely to have differing scheduler > characteristics across different implementations. > > So rather than assign these instructions a generic "bitmanip" type, this > patch assigns them a type based on their RTL code by using the > <bitmanip_insn> iterator for the type. Naturally we have to add a few > new types. It affects clz, ctz, cpop, min, max. > > We didn't do this for things like shNadd, single bit manipulation, etc. > We certainly could if the needs presents itself. > > I threw all the new types into the generic_alu bucket in the generic > scheduling model. Seems as good a place as any. Someone who knows the > sifive uarch should probably add these types (and bitmanip) to the > sifive scheduling model. > > We also noticed that the recently added orc.b didn't have a type at all. > So we added it as a generic bitmanip type. > > This has been bootstrapped in a gcc-12 base and I've built and run the > testsuite without regressions on the trunk. > > Given it was primarily Raphael's work I could probably approve & commit > it. But I'd like to give the other RISC-V folks a chance to chime in. > > > OK for the trunk? > > Jeff
