GNU bug report logs - #53895
[PATCH 0/5] More CPU detection

Previous Next

Package: guix-patches;

Reported by: Efraim Flashner <efraim <at> flashner.co.il>

Date: Wed, 9 Feb 2022 10:19:01 UTC

Severity: normal

Tags: patch

Done: Efraim Flashner <efraim <at> flashner.co.il>

Bug is archived. No further changes may be made.

Full log


Message #29 received at 53895 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 53895 <at> debbugs.gnu.org
Subject: Re: bug#53895: [PATCH 0/5] More CPU detection
Date: Wed, 9 Feb 2022 12:45:35 +0200
[Message part 1 (text/plain, inline)]
On Wed, Feb 09, 2022 at 11:35:22AM +0100, Ludovic Courtès wrote:
> Hi!
> 
> Efraim Flashner <efraim <at> flashner.co.il> skribis:
> 
> > * guix/cpu.scm (cpu->gcc-architecture): Rewrite detection based on
> > detected feature flags.
> 
> [...]
> 
> >       ;; Transcribed from GCC's 'host_detect_local_cpu' in driver-i386.c.
> >       (or (and (= 6 (cpu-family cpu))              ;the "Pentium Pro" family
> > -              (letrec-syntax ((model (syntax-rules (=>)
> > -                                       ((_) #f)
> > -                                       ((_ (candidate => integers ...) rest
> > -                                           ...)
> > -                                        (or (and (= (cpu-model cpu) integers)
> > -                                                 candidate)
> > -                                            ...
> > -                                            (model rest ...))))))
> > -                (model ("bonnel" => #x1c #x26)
> > -                       ("silvermont" => #x37 #x4a #x4d #x5a #x5d)
> > -                       ("core2" => #x0f #x17 #x1d)
> > -                       ("nehalem" => #x1a #x1e #x1f #x2e)
> > -                       ("westmere" => #x25 #x2c #x2f)
> > -                       ("sandybridge" => #x2a #x2d)
> > -                       ("ivybridge" => #x3a #x3e)
> > -                       ("haswell" => #x3c #x3f #x45 #x46)
> > -                       ("broadwell" => #x3d #x47 #x4f #x56)
> > -                       ("skylake" => #x4e #x5e #x8e #x9e)
> > -                       ("skylake-avx512" => #x55) ;TODO: cascadelake
> > -                       ("knl" => #x57)
> > -                       ("cannonlake" => #x66)
> > -                       ("knm" => #x85))))
> > +              (letrec-syntax ((if-flags (syntax-rules (=>)
> > +                                          ((_)
> > +                                           #f)
> > +                                          ((_ (flags ... => name) rest ...)
> > +                                           (if (every (lambda (flag)
> > +                                                        (set-contains? (cpu-flags cpu)
> > +                                                                       flag))
> > +                                                      '(flags ...))
> > +                                             name
> > +                                             (if-flags rest ...))))))
> > +
> > +                (if-flags ("avx" "avx512vp2intersect" "tsxldtrk" => "sapphirerapids")
> > +                          ("avx" "avx512vp2intersect" => "tigerlake")
> > +                          ("avx" "avx512bf16" => "cooperlake")
> > +                          ("avx" "wbnoinvd" => "icelake-server")
> > +                          ("avx" "avx512bitalg" => "icelake-client")
> > +                          ("avx" "avx512vbmi" => "cannonlake")
> 
> In current master, the logic is:
> 
>   if it’s an intel
>   then pick the model ID
>   if that didn’t work
>   then do feature-based detection
> 
> Here you’re removing the first part (using the Intel model ID) and
> extending the second part.  Perhaps we could extend the second part but
> still keep the first one?
> 
> The AMD detection code would have to go before the generic fallback case
> though.
> 
> WDYT?
> 
> Ludo’.

in gcc-11 driver-i386.c is modified to use the 'vendor' to choose the
'processor', and then using the processor flag it runs through a list of
if statements to check feature flags, so that's what I was following.

-- 
Efraim Flashner   <efraim <at> flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 3 years and 97 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.