Default ISA/tuning flags for GCC, --enable-kernel= level for glibc

Mon Jan 26 11:06:49 UTC 2009

On Monday, 26 January 2009 at 11:15, Jakub Jelinek wrote:
> Hi!
> 
> dist-f11-gcc44 currently has gcc 4.4.0-0.X packages, which are almost ready
> for moving into dist-f11, but before doing that, I'd like to discuss
> defaults.  gcc on most arches has a switch to select which ISA it can assume
> (i.e. what minimum CPU will gcc compiled code run on) and a separate option
> to tune for the same or other CPU.  Currently in Fedora the tuning is
> I believe:
> 		ISA		 tuning
> i386		-march=i386	 -mtune=generic
> x86_64		-march=x86-64	 -mtune=generic
> ppc		lowest		 -mtune=power6
> ppc64		lowest		 -mtune=power6
> s390		-march=g5	 -mtune=z9-109
> s390x		-march=z900	 -mtune=z9-109
> ia64		lowest		 -mtune=itanium2
> sparc		-mcpu=v7	 -mtune=v7
> sparcv9		-mcpu=v7	 -mtune=v7
> sparc64		-mcpu=ultrasparc -mtune=ultrasparc
> 
> plus redhat-rpm-config tweaks something (-fasynchronous-unwind-tables
> and -mminimal-toc tweaking should IMHO remain in redhat-rpm-config):
> i686		-march=i686	 -mtune=generic
> sparc		-mcpu=v7	 -mtune=ultrasparc
> sparcv9		-mcpu=ultrasparc -mtune=ultrasparc
> 
> The question is, do we want to change anything on this for F11?
> E.g. I believe Fedora hasn't shipped an i386 or i486 kernel for years,
> and especially the -march=i386 vs. -march=i486 difference is significant
> (-march=i386 doesn't have sufficient atomic instructions).  The only
> -lpthread library we are using is NPTL and that doesn't support i386
> anyway, so I think we should either use -march=i486 or -march=i586
> (the latter has 8 byte compare and swap instruction) as the default,
> when -march= isn't specified.

I don't know about non-x86 arches (it's probably less of a problem), but
for x86 such change can (as you probably know) affect the overall speed
of the generated code and must be benchmarked. I would be in favour of
changing the default cflags to include -march=i586 if it gives measurable
benefits, i.e. faster binaries and/or smaller code size, but slower binaries
are not acceptable.

[...]
> Another question is if we finally could bump the minimum supported kernel
> version in Fedora 11 glibc.  Currently Fedora 10 glibc requires 2.6.9 or
> later kernel, which means it can't assume a lot of stuff (e.g. private
> futexes, a lot of added syscalls etc.), which means it has to test for them
> at runtime of every program (e.g. every threaded program does a dummy futex
> syscall to check for private futexes, for futex realtime clock support and
> has to use variables for this, instead of oring constants in the mutexes
> etc., and glibc has to check for ENOSYS and have fallbacks compiled in).
> 2.6.9 default comes I think still from the RHEL4 kernels.
> Could we bump this ideally to 2.6.29?  It would mean Fedora 11 userland
> only runs on 2.6.29 and later kernels, but we could gain speed and decrease
> size of glibc shared libraries.

Could you elaborate more on why it gives a speedup (along with some
benchmarks, preferably) or at least give some links to explanations? If it
really gives us more speed, I'm all for it. One issue to consider, though
is that it'd be impossible to run an OpenVZ-virtualized Fedora 11 instance
on an earlier kernel, but I guess that's a minor issue.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"