[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FPU avoidance idea

Ben Pfaff <pfaffben@pilot.msu.edu> writes:

> I think that you should probably discuss this with Ulrich Drepper
> before doing it.  There was a long discussion about this very issue
> (setting the fpu control word at every program startup) on the
> linux-kernel list a number of months ago, and I don't remember exactly
> what the conclusion came to be.

I read a bit of that at the time (but didn't really understand it).

I reviewed the latest on the topic, try reading some of this thread:


I still don't completely understand the issue, but it seems to come
down to the fact that Ulrich and Linus can't agree on what to do here.

Linus says that programs can rely on the kernel initializing the fpu
cw setting (whatever that is) which the kernel sets at execve time,
and glibc shouldn't have to touch it during initialization.  Dave
Miller agrees with this.  

Ulrich argues that the setting could change at some time in the
future, and he doesn't want programs which depend on that setting to
be affected when Linus changes it sometime in the future.  Linus says
that is never going to happen.

Jakub Jelinek posted a patch that "exports the default value of FPU
control word in the ELF auxiliary vector, so that libc can look at it
and avoid touching FPU just to initialize it to the default value".

Linus refused to apply it - as he feels that the runtime check would
impose additional, unnecessary overhead on every program invocation --
because he argues that glibc should just trust the default the kernel
sets, which he is never going to change.

Dave Miller is siding with Linus on this, and it sounds like he is
going to patch glibc on the Sparc to do it the way Linux wants.

Linus wants maximum performance, whereas Ulrich wants to "play it
safe".  I can understand both of their viewpoints.

Needless to say, I definitely don't want to wade into the middle of
this.  Hopefully, Linus and Ulrich can settle this.  If Philip, Corel
or Debian decide to patch glibc, I'll go with that.  Otherwise, the
LD_PRELOAD hack seems like a quick-and-easy solution for the


 - Jim

Reply to: