| Message ID | 12026d29411b4ef0597d2f40d874ad2fcc49a087.1687247150.git.efraim@flashner.co.il |
|---|---|
| State | New |
| Headers | show |
| Series | More package tuning | expand |
Efraim Flashner <efraim@flashner.co.il> skribis: > * guix/cpu.scm (gcc-architecture->generic-architecture): New variable. [...] > +(define (gcc-architecture->generic-architecture gcc-architecture) > + "Return a generalized micro-architecture, using an inexact matching to provide > +'good enough' optimizations." > + (match gcc-architecture Let’s call it ‘gcc-architecture->micro-architecture-level’, with a docstring that makes it’s clear that this is about x86_64 micro-architecture levels. Please also add a comment stating how to figure out what goes where so we can more easily keep it up-to-date. I guess this procedure is good enough for Go support, right? Thanks, Ludo’.
On Sun, Jun 25, 2023 at 10:54:38PM +0200, Ludovic Courtès wrote: > Efraim Flashner <efraim@flashner.co.il> skribis: > > > * guix/cpu.scm (gcc-architecture->generic-architecture): New variable. > > [...] > > > +(define (gcc-architecture->generic-architecture gcc-architecture) > > + "Return a generalized micro-architecture, using an inexact matching to provide > > +'good enough' optimizations." > > + (match gcc-architecture > > Let’s call it ‘gcc-architecture->micro-architecture-level’, with a > docstring that makes it’s clear that this is about x86_64 > micro-architecture levels. Sounds good to me. We can change the docstring if we end up adding support for more architectures (ie ppc64le). > Please also add a comment stating how to figure out what goes where so > we can more easily keep it up-to-date. > > I guess this procedure is good enough for Go support, right? It would be better if we could populate x86_64-v4 and x86_64-v2, but I really didn't feel like I could comfortably draw the line anywhere and be sure I had the correct CPUs. If someone comes along and says they're sure their CPU should be in -v2 or -v4 then I/someone can check the gcc sources to make sure that's the case. I'm pretty sure there's other compilers out there that also use the psABI for tuning, my first look would be GHC. From my testing it does work for Go, and since we're using an official definition for the psABIs and not just Go's definitions I'm pretty confident it'll be useful for something else, somewhere. > Thanks, > Ludo’. Thanks for your review!
diff --git a/guix/cpu.scm b/guix/cpu.scm index ddfa4f20bb..af26e2280b 100644 --- a/guix/cpu.scm +++ b/guix/cpu.scm @@ -33,7 +33,8 @@ (define-module (guix cpu) cpu-flags cpu->gcc-architecture - cpu->generic-architecture)) + cpu->generic-architecture + gcc-architecture->generic-architecture)) ;;; Commentary: ;;; @@ -284,3 +285,21 @@ (define (cpu->generic-architecture cpu) (architecture ;; TODO: More architectures architecture))) + +(define (gcc-architecture->generic-architecture gcc-architecture) + "Return a generalized micro-architecture, using an inexact matching to provide +'good enough' optimizations." + (match gcc-architecture + ((or "grandridge" "graniterapids" "sierraforest" "tigerlake" + "sapphirerapids" "cooperlake" "icelake-server" "icelake-client" + "cannonlake" "knm" "knl" "skylake-avx512" "alderlake" "skylake" + "broadwell" "haswell" + "znver4" "znver3" "znver2" "znver1" "bdver4") + "x86_64-v3") + ((or "sandybridge" "tremont" "goldmont-plus" "goldmont" "silvermont" + "nehalem" "bonnell" "core2" + "btver2" "athalon" "k8-sse3" "k8" "bdver3" "bdver2" "bdver1" "btver1" + "amdfam10" + "lujiazui" "x86-64") + "x86_64-v1") + (_ gcc-architecture)))