This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: i386 alignment tweaks...



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]