Wilco Dijkstra <wilco.dijks...@arm.com> writes: > Hi Richard, > >>> Essentially anything covered by HWCAP doesn't need an explicit check. So I >>> kept >>> the LS64 and PREDRES checks since they don't have a HWCAP allocated (I'm not >>> entirely convinced we need these, let alone having 3 individual bits for >>> LS64, but >>> that's something for the ACLE spec to sort out). The goal here is to fix >>> all obvious >>> bugs so one can use FMV as intended. >> >> Didn't we take the opposite approach for libatomic though? > > We started the work before LSE128/RCPC3 HWCAPs were added, so there was no > alternative at the time. Checking both means a higher QoI, but once most > distros > use modern kernels, the CPUID checks become unnecessary and will be removed. > >> I suppose one difference is that the libatomic code is gating a >> choice between a well-defined, curated set of routines, whereas the >> libgcc code is providing a general user-facing feature. So maybe >> libgcc should be more conservative for that reason? > > Indeed. Using HWCAP means it's trivially correct and working identically > between GCC > and LLVM. > > I don't rule out adding extra CPUID checks for some features. However unlike > libatomic, > the selected features are very user visible, so we would need to specify for > which features > this is both useful and correct, and make sure GCC and LLVM behave in the > same way.
Thanks, makes sense. On that basis, the patch is OK for trunk and GCC 14 branch with the previously discussed changes to the changelog & commit message. Richard
