Date: Fri, 02 Oct 2015 08:26:10 -0600 From: Ian Lepore <ian@freebsd.org> To: Konstantin Belousov <kib@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r288492 - head/sys/arm/arm Message-ID: <1443795970.66572.68.camel@freebsd.org> In-Reply-To: <201510021326.t92DQ0Ds002986@repo.freebsd.org> References: <201510021326.t92DQ0Ds002986@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2015-10-02 at 13:26 +0000, Konstantin Belousov wrote: > Author: kib > Date: Fri Oct 2 13:25:59 2015 > New Revision: 288492 > URL: https://svnweb.freebsd.org/changeset/base/288492 > > Log: > Do not set 'flush to zero' VFPSCR_FZ bit by default. The correct > implementation of IEEE 754 arithmetic depends on denormals operating > correctly. Both perl test suite and paranoia tripped over the > setting. > > Reported by: Stefan Parvu <sparvu@kronometrix.org> > Discussed with: andrew > Sponsored by: The FreeBSD Foundation > MFC after: 1 week > > Modified: > head/sys/arm/arm/machdep.c > head/sys/arm/arm/vm_machdep.c > > Modified: head/sys/arm/arm/machdep.c > ============================================================================== > --- head/sys/arm/arm/machdep.c Fri Oct 2 13:21:08 2015 (r288491) > +++ head/sys/arm/arm/machdep.c Fri Oct 2 13:25:59 2015 (r288492) > @@ -1069,7 +1069,7 @@ init_proc0(vm_offset_t kstack) > (thread0.td_kstack + kstack_pages * PAGE_SIZE) - 1; > thread0.td_pcb->pcb_flags = 0; > thread0.td_pcb->pcb_vfpcpu = -1; > - thread0.td_pcb->pcb_vfpstate.fpscr = VFPSCR_DN | VFPSCR_FZ; > + thread0.td_pcb->pcb_vfpstate.fpscr = VFPSCR_DN; > thread0.td_frame = &proc0_tf; > pcpup->pc_curpcb = thread0.td_pcb; > } > > Modified: head/sys/arm/arm/vm_machdep.c > ============================================================================== > --- head/sys/arm/arm/vm_machdep.c Fri Oct 2 13:21:08 2015 (r288491) > +++ head/sys/arm/arm/vm_machdep.c Fri Oct 2 13:25:59 2015 (r288492) > @@ -134,7 +134,7 @@ cpu_fork(register struct thread *td1, re > pcb2->pcb_regs.sf_sp = STACKALIGN(td2->td_frame); > > pcb2->pcb_vfpcpu = -1; > - pcb2->pcb_vfpstate.fpscr = VFPSCR_DN | VFPSCR_FZ; > + pcb2->pcb_vfpstate.fpscr = VFPSCR_DN; > > tf = td2->td_frame; > tf->tf_spsr &= ~PSR_C; > Some arm documentation refers to the need for "support code" when the flush-to-zero option is disabled on VFPv2 hardware (which for us would be just the RPi I think). Do we have that support code? What happens if it's missing? I can't actually find any info on exactly what that support code is supposed to do. For all I know, we have the required code in libm. Or maybe what's needed is exception-handling code in the kernel. I can't find any info on what they mean by "support code" in this context. I don't think this is an issue for VFPv3 and later hardware. I've looked in a few of the TRMs for different cortex-a series processors and they say the hardware handles all combinations of rounding and flush to zero without support software. But we should probably be on the lookout for reports of misbehaving apps on RPi after this change, just in case this setting has been protecting us from our ignorance there. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1443795970.66572.68.camel>