You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...).
The text was updated successfully, but these errors were encountered:
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...).
The text was updated successfully, but these errors were encountered: