On Mon, Dec 09, 2024 at 06:37:22PM +0100, Ludovic Courtès wrote: > Hello, > > Efraim Flashner skribis: > > > I saw a post by Marcan¹ of Asahi Linux the other day about not parsing > > /proc/cpuinfo and remembered that's what we're doing in (guix cpu). > > I believe it initially mimicked what GCC does for ‘-march=native’, but > it does seem to be less exhaustive than /sys/devices/cpu/modalias. > > I wonder if there are version/portability issues with the latter. I've been thinking more about it over the past few days. I think ultimately we need to match both parts; the kernel interfaces with the hardware and knows (or at least should know) exactly what the hardware can support, and gcc (or the other compilers) need to support optimizing for those hardware bits specifically. Also, parsing /proc/cpuinfo is already reading what the kernel says it supports, except in an incomplete manner. Starting with x86_64 (and i686), I think we keep GCC's definition of what each sub-architecture is but parse the modalias file instead of parsing cpuinfo. I already have some code to parse modalias and some ideas for just reusing the math bits from the kernel (it looks like ((11*32)+28) for zen2) to adjust the if-flags to match the numerical equivalent of the feature. For x86_64 the kernel does have a policy of reusing flags if they've been deprecated and unused long enough, but hopefully that won't be a problem, even with some of our older LTS kernels. I think for the start it would make most sense to read modalias in addition to cpuinfo, sort based on the data in modialis, and then fallback to cpuinfo if it doesn't match. This helps for architectures without the modalias file (like riscv64), and I don't know what the Hurd provides, but I'd be surprised if it had the same modalias file for parsing. I'll try to work on it a bit over the coming days. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted