This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: i386 alignment tweaks...
- To: torvalds at transmeta dot com (Linus Torvalds)
- Subject: Re: i386 alignment tweaks...
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Fri, 14 Jan 2000 02:13:26 -0700
- cc: gcc-patches at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
Linus -- please fix your local relay to use gcc-patches or egcs-patches for
the outoing "To" line.
People are complaining that your local relay (submit-linux-egcs-pathches) is
mucking up procmail filters and whatnot.
In message <85mn7v$3th$1@penguin.transmeta.com>you write:
> Right now, very few programs use floating point regularly. Which means
> that pretty much every operating system on the x86 does lazy FP state
> saves and restores, or at least optimizes them away for processes that
> do not touch their FP state during a timeslice.
It's not just the x86 world. Every modern system I've worked with that
had an FPU will lazily context switch the FP registers.
The x86 is a bloody joke in this regard as it only has 8 FP registers to
worry about -- context switching 32 or 64 FP regs is bloody painful.
It's also a major lose if the kernel has been declared a strict no FP
zone. I've worked on kernels in the past where that is the case and in
fact performing an FPU instruction without explicit setup would crash
the kernel :(
> If you start sprinking random FP state into binaries, you suddenly get
> inexplicable slowdowns in critical areas - yet your benchmarks that you
> use to "validate" your work will clearly show that it's a win.
> Especially if you run such a benchmark on a system where the "normal"
> binaries do not use FP.
Yup. And in general the throughput improvements for using FP loads/stores
to do this kind of thing just aren't enough to overcome the pain of lazy
context switching the FPU.
Like Linus, I feel this change is a major mistake.
jeff