On Thu Sep 22, 2022 at 1:22 AM AEST, Segher Boessenkool wrote: > Hi! > > On Wed, Sep 21, 2022 at 11:01:18AM +1000, Nicholas Piggin wrote: > > On Wed Sep 21, 2022 at 8:16 AM AEST, Segher Boessenkool wrote: > > > On Tue, Sep 20, 2022 at 12:01:47AM +1000, Nicholas Piggin wrote: > > > > Update the 64s GENERIC_CPU option. POWER4 support has been dropped, so > > > > make that clear in the option name. > > > > > > AFAIR the minimum now is POWER4+ (ISA 2.01), not POWER5 (ISA 2.02). > > > > It's POWER5 now, because of commit 471d7ff8b5 ("powerpc/64s: Remove > > POWER4 support"), which is misguided about POWER4+ and also introduced > > the -mcpu=power5 bug on 970 builds :\ > > ISA 2.01 added just a few things (LPES[0], HDEC, some PM things, but > crucially also anything that sets MSR[PR] also sets MSR[EE] since then).
Ah, right. Some Book3 cleanups mainly. > > Not sure it's worth adding POWER4+ support back but if someone has a > > POWER4+ or adds it to QEMU TCG, I will do the patch. > > 970 is 2.01 -- pretending it is 2.02 is a ticking time bomb: the popcntb > insn will be generated for popcount and parity intrinsics, which can be > generated by generic code! Yeah agreed, it was an error on my part with that original patch. > > > > -mtune= before power8 is dropped because the minimum gcc version > > > > supports power8, and tuning is made consistent between big and little > > > > endian. > > > > > > Tuning for p8 on e.g. 970 gives quite bad results. No idea if anyone > > > cares, but this is a serious regression if so. > > > > It's for "generic" kernel so we set low minimum but higher tune, > > assuming that people would usually have newer, so it was already > > doing -mtune=power7. > > > > We could make a specific 970/G5 entry though, since those still > > have users. > > If that uses -mcpu=power4 (which means ISA 2.01 btw!) all is fine > already? (Or -mcpu=970, same thing really, it just allows VMX as well). Well it does -mcpu=power4 but the "generic" CPU option also does the -mtune=power7 or 8. I added a -mcpu=970 version, even though we don't let the compiler generate VMX in the kernel so I guess it's not functionally different. > Thanks for taking care of this Nick, much appreciated! No problem, thanks for reviewing and finding my errors :P Thanks, Nick