We currently never assume that FPU state is preserved across a call to REPLY and a subsequent entry through a portal. The way the code is structured would even make it very hard to find a good usecase for accessing the FPU state left from servicing the last portal call.
Would it make sense to change the semantics of REPLY to not preserve FPU state, i.e. setting fpowner = nullptr on REPLY? It should save a call to fpu->save() in a lot of cases, with no ill side effects, except for the minor tidbit that when a EC accesses the FPU upon serving a subsequent portal call, it will see stale content (if it were to look, which it isn't...).
We currently never assume that FPU state is preserved across a call to REPLY and a subsequent entry through a portal. The way the code is structured would even make it very hard to find a good usecase for accessing the FPU state left from servicing the last portal call.
Would it make sense to change the semantics of REPLY to not preserve FPU state, i.e. setting fpowner = nullptr on REPLY? It should save a call to fpu->save() in a lot of cases, with no ill side effects, except for the minor tidbit that when a EC accesses the FPU upon serving a subsequent portal call, it will see stale content (if it were to look, which it isn't...).