To echo Jacob's comment, C/C++ code cannot change the rounding mode, so if we are not in the default rounding mode when entering JS code this was done intentionally and I'd argue that whatever code did it should restore the default before returning to JS code. Assert in VFPEnsureFPSCRState will help here.
On 4 April 2014 16:36, <jacob.bram...@arm.com> wrote: > On 2014/04/04 15:16:07, oetuaho-nv wrote: > >> On 2014/04/04 14:34:42, jbramley wrote: >> > On 2014/04/04 14:14:17, oetuaho-nv wrote: >> > > On 2014/04/04 09:43:05, jbramley wrote: >> > > > I can't find any use of vmsr that sets the rounding mode to >> > > > anything else. A few tests hit it, but the rounding mode is >> > > > correct in every case. Under what conditions can FPSCR be wrong >> > > > here? >> > > >> > > Yes, it's not being set by other code generated by v8, but is >> > > there anything preventing other code that runs in the same >> > > execution context setting the FPSCR to another value? >> > >> > Sort of, yes. AAPCS (the procedure-call standard) says that the >> > rounding-mode bits may be modified by "specific support functions >> > that affect the global state of the application". That is, we would >> > have to do it explicitly somewhere. >> > > To me, that reads as you can't rely on the bits being set a certain >> way, unless I'm understanding "global state of the application" wrong >> somehow. Isn't this state shared with the entire renderer main thread >> in the case of Chromium, for example, which is running all sorts of >> code? >> > > Yes, indeed, but by the same logic, if a project (such as Chromium) > wants to change the arithmetic settings, it must ensure that this change > is acceptable for its components (such as V8). > > An assertion in VFPEnsureFPSCRState would be sufficient to enforce this, > I think. > > > I'm also curious about the NaN bit, according to AAPCS bit 25 is one >> of the "other" bits that must not be modified, yet it is modified in >> VFPEnsureFPSCRState? >> > > Yes, I wondered about that too. We modify it because we rely on > default-NaN mode to optimize some NaN canonicalization operations. AAPCS > says that this is non-compliant, but in this case it is probably a > worthwhile non-compliance. > > We restore it when returning to (or calling) C++ code so the impact will > be limited to signal handlers. In general, C++ code doesn't care much > about default-NaN mode. This could be a problem later, but I think it's > quite unlikely. > > > > https://codereview.chromium.org/222403002/ > > -- > -- > v8-dev mailing list > v8-dev@googlegroups.com > http://groups.google.com/group/v8-dev > ---You received this message because you are subscribed to the Google > Groups "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to v8-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
