GNU bug report logs - #64188
[PATCH 0/8] More package tuning

Previous Next

Full log

View this message in rfc822 format

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Josselin Poiret <dev <at> jpoiret.xyz>, Tobias Geerinckx-Rice <me <at> tobias.gr>, Simon Tournier <zimon.toutoune <at> gmail.com>, Mathieu Othacehe <othacehe <at> gnu.org>, Christopher Baines <mail <at> cbaines.net>, 64188 <at> debbugs.gnu.org, Ricardo Wurmus <rekado <at> elephly.net>
Subject: [bug#64188] [PATCH 0/8]  More package tuning
Date: Mon, 26 Jun 2023 11:34:38 +0300

[Message part 1 (text/plain, inline)]

On Sun, Jun 25, 2023 at 10:47:42PM +0200, Ludovic Courtès wrote:
> Hello Efraim,
> 
> Efraim Flashner <efraim <at> flashner.co.il> skribis:
> 
> > with gcc-11, gcc gained support for using -march=x86_64-v{1,2,3,4},
> > which I'm calling 'generic options,' as opposed to the more targeted
> > tuning we have with specific architectures.
> 
> I don’t think these x86_64 psABI “architecture levels” should be treated
> specially:
> 
>   • From the point of view of ‘--tune’, they’re just another value that
>     may be passed to ‘-march’.
> 
>   • My understanding is that those levels don’t match reality: as
>     discussed in the original ‘--tune’ patch¹, CPUs actually produced
>     don’t follow a pattern of strictly including features of one set.
>     They’re really just a simplification to get more memorizable names,
>     but it’s hard to tell whether a given CPU really covers the set of
>     features of a given level.

They're also useful for glibc-hwcaps, so that we could build each
package multiple times and install libraries built for the psABI levels
into $prefix/lib/glibc-hwcaps/x86-64-v[234]/, but I agree that, for our
uses so far, they're not really useful.

> Overall, my take on this would be to add supported levels to
> ‘%gcc-11-x86_64-micro-architectures’ & co., without going further.
> 
> WDYT?

I could see keeping the code from cpu->generic-architecture (renamed
cpu->psABI) either as a non-exported function or simply moved into the
fallback for x86_64.

> ¹ https://issues.guix.gnu.org/52283#0-lineno48
> 
> [...]
> 
> > go cpu tuning targets: I mostly used the chart¹ on the go website, and I
> > also checked the source code for go-1.18. I put in arm{5,6,7} as arm and
> > not armhf since armhf only works with armv7 and with go programs, since
> > they're statically linked, they can just be copied to other machines.
> 
> Now if Go uses those names, (guix cpu) can provide helpers.

Go also uses power8 and power9 as PPC64(le) options, so that's also a
possible use-case I was trying to also prepare for. That was my plan for
the gcc-architecture->generic-architecture function, to allow for --tune
to work without needing to pass different values to different packages.

-- 
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)]

Previous Next

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