sched: avoid unnecessary FPU saving

Because of Linux's calling convention, it should not be necessary to
save the FPU state when a reschedule is caused by a function call.

Because we had a bug and forgot to save the FPU state when calling
a signal handler, and because this signal handler can cause a reschedule,
we had to save the FPU on any reschedule. But after fixing that bug, we
no longer need these unnecessary FPU saves.

The "sunflow" benchmark still runs well after this patch.

core/sched.cc

@@ -93,22 +93,11 @@ void cpu::reschedule_from_interrupt(bool preempt)
     if (n != thread::current()) {
         if (preempt) {
             p->_fpu.save();
-        } else {
-            // FIXME: In this case, in theory, we do not need to save the FPU
-            // state (perhaps just mxcsr and cw) because we got here through a
-            // function call and the calling conventions guarantee the caller
-            // clears the FPU state. Unfortunately, in practice, the SPECjvm
-            // "sunflow" benchmark breaks (gets wrong results) if we don't
-            // save the SSE registers here. We don't know why.
-            p->_fpu.save();
         }
         trace_switch(n);
         n->switch_to();
         if (preempt) {
             p->_fpu.restore();
-        } else {
-            // FIXME: This shouldn't be here! See comment above.
-            p->_fpu.restore();
         }
     }
 }

todo/fpu

 Avoiding unnecessary FPU state saving
 =====================================
 
-1. Understand why the "sunflow" benchmark fails unless we also save FPU
-   state on reschedule_from_interrupt with !preempt:
-
-   1. One guess is that Java has a bug where it doesn't follow the calling
-      conventions and doesn't save its fpu state before calling some library
-      function. Avi tried to reproduce this in Linux (with a layer that
-      ruins the FPU state before calling library functions) and couldn't
-      so this may not be the correct explanation.
-
-   2. Another guess (by Avi) is that a signal handler is involved and
-      we don't save the FPU on signals! Need to fix that.
-
 2. Even if we don't need to save the whole fpu state on !preempt, we probably
    need to save the fcw and mxcsr.
-
-3. If for some reason (?) this problem is unfixable and we must (why?) save
-   FPU on every context switch, we may be forced to consider lazy FPU
-   switching - which we tried to avoid.