[parisc-linux] [glibc] fixing delayed exceptions in hppa

[parisc-linux] [glibc] fixing delayed exceptions in hppa

[Carlos O'Donell]

parisc-linux,

Just a quick RFC on this patch. I've generated a register interlock on
the previous exception raising result register. This _should_ cause delayed
exceptions to be flushed immediately on all processors.

Under my C3K testsetup it fixes the test-fenv failure that was
specifically related to "child raises exception, exception comes in late
and kills parent after child called join."

Comments more than welcome, I'll be submitting this upstream if nobody
has any quibles with my gcc asm :)

c.

--- libc/sysdeps/hppa/fpu/fraiseexcpt.c	10 Sep 2002 01:26:37 -0000	1.4
+++ libc/sysdeps/hppa/fpu/fraiseexcpt.c	19 Aug 2003 18:52:33 -0000
@@ -25,6 +25,8 @@
 int
 feraiseexcept (int excepts)
 {
+  /* Used in the trap barrier */
+	double dummy;
   /* Raise exceptions represented by EXCEPTS.  But we must raise only one
      signal at a time.  It is important that if the overflow/underflow
      exception and the divide by zero exception are given at the same
@@ -42,17 +44,17 @@ feraiseexcept (int excepts)
     {
       /* One example of a invalid operation is 0 * Infinity.  */
       double d = HUGE_VAL;
-      __asm__ __volatile__ ("fmpy,dbl %1,%%fr0,%0\n\t"
+      __asm__ __volatile__ ("fmpy,dbl %2,%%fr0,%0\n\t"
 			    /* FIXME: is this a proper trap barrier? */
-			    "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d));
+			    "fcpy,dbl %0,%1" : "=f" (d), "=f" (dummy) : "0" (d));
     }
 
   /* Next: division by zero.  */
   if (excepts & FE_DIVBYZERO)
     {
       double d = 1.0;
-      __asm__ __volatile__ ("fdiv,dbl %1,%%fr0,%0\n\t"
-			    "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d));
+      __asm__ __volatile__ ("fdiv,dbl %2,%%fr0,%0\n\t"
+			    "fcpy,dbl %2,%1" : "=f" (d), "=f" (dummy) : "0" (d));
     }
 
   /* Next: overflow.  */
@@ -61,8 +63,8 @@ feraiseexcept (int excepts)
     {
       double d = DBL_MAX;
 
-      __asm__ __volatile__ ("fmpy,dbl %1,%1,%0\n\t"
-			    "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d));
+      __asm__ __volatile__ ("fmpy,dbl %2,%2,%0\n\t"
+			    "fcpy,dbl %2,%1" : "=f" (d), "=f" (dummy) : "0" (d));
     }
 
   /* Next: underflow.  */
@@ -71,8 +73,8 @@ feraiseexcept (int excepts)
       double d = DBL_MIN;
       double e = 69.69;
 
-      __asm__ __volatile__ ("fdiv,dbl %1,%2,%0\n\t"
-			    "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d), "f" (e));
+      __asm__ __volatile__ ("fdiv,dbl %2,%3,%0\n\t"
+			    "fcpy,dbl %2,%1" : "=f" (d), "=f" (dummy) : "0" (d), "f" (e));
     }
 
   /* Last: inexact.  */
@@ -81,8 +83,8 @@ feraiseexcept (int excepts)
       double d = 1.0;
       double e = M_PI;
 
-      __asm__ __volatile__ ("fdiv,dbl %1,%2,%0\n\t"
-			    "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d), "f" (e));
+      __asm__ __volatile__ ("fdiv,dbl %2,%3,%0\n\t"
+			    "fcpy,dbl %2,%1" : "=f" (d), "=f" (dummy) : "0" (d), "f" (e));
     }
 
   /* Success.  */

Re: [parisc-linux] [glibc] fixing delayed exceptions in hppa

[Matthew Wilcox]

On Thu, Aug 21, 2003 at 09:39:31PM -0400, Carlos O'Donell wrote:
> Just a quick RFC on this patch. I've generated a register interlock on
> the previous exception raising result register. This _should_ cause delayed
> exceptions to be flushed immediately on all processors.
> 
> Under my C3K testsetup it fixes the test-fenv failure that was
> specifically related to "child raises exception, exception comes in late
> and kills parent after child called join."

Yay.

> Comments more than welcome, I'll be submitting this upstream if nobody
> has any quibles with my gcc asm :)

I can quibble!

>        /* One example of a invalid operation is 0 * Infinity.  */
>        double d = HUGE_VAL;
> -      __asm__ __volatile__ ("fmpy,dbl %1,%%fr0,%0\n\t"
> +      __asm__ __volatile__ ("fmpy,dbl %2,%%fr0,%0\n\t"
>  			    /* FIXME: is this a proper trap barrier? */
> -			    "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d));
> +			    "fcpy,dbl %0,%1" : "=f" (d), "=f" (dummy) : "0" (d));
>      }

Surely this, and all the others, would be clearer written as:

	__asm__ __volatile__ (
		"	fmpy,dbl %0,%%fr0,%0\n"
		"	fcpy,dbl %0,%1\n"
		: "+f" (d), "=f" (dummy));

ie turn the \t into a literal tab, and use the "+" syntax rather than the
"=" and "0" syntax.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

[parisc-linux] Re: [glibc] fixing delayed exceptions in hppa

[John David Anglin]

> Comments more than welcome, I'll be submitting this upstream if nobody
> has any quibles with my gcc asm :)

See <http://lists.parisc-linux.org/hypermail/parisc-linux/10549.html>.

Dave

[parisc-linux] Re: [glibc] fixing delayed exceptions in hppa

[Carlos O'Donell]

On Thu, Aug 21, 2003 at 11:04:44PM -0400, John David Anglin wrote:
> > Comments more than welcome, I'll be submitting this upstream if nobody
> > has any quibles with my gcc asm :)
> 
> See <http://lists.parisc-linux.org/hypermail/parisc-linux/10549.html>.

I took this into account, and the fcpy of a non fr0 is working better
than before precisely for the reasons you list your original email.

Should I instead spill the value into memory at dummy's address?

c.

[parisc-linux] Re: [glibc] fixing delayed exceptions in hppa

[John David Anglin]

> I took this into account, and the fcpy of a non fr0 is working better
> than before precisely for the reasons you list your original email.
> 
> Should I instead spill the value into memory at dummy's address?

Based on what Jim Hull said, I believe that would be better.  I was using

  "fldd 0(%%sr0,%%sp),%0" : "=f" (d) : "0" (d)

There isn't a true dependency in the above but I believe that any load
to the destination register will raise the exception.

Dave

Re: [parisc-linux] Re: [glibc] fixing delayed exceptions in hppa

[Carlos O'Donell]

On Fri, Aug 22, 2003 at 04:24:19PM -0400, John David Anglin wrote:
> Based on what Jim Hull said, I believe that would be better.  I was using
> 
>   "fldd 0(%%sr0,%%sp),%0" : "=f" (d) : "0" (d)
> 
> There isn't a true dependency in the above but I believe that any load
> to the destination register will raise the exception.

Dave, I'm sorry if you sent me a patch and I dropped it :( Did I ever
receive a diff for this from you?

It's rather vague at times because the spec says "or an operation which
depends on a pending, trapping insn." I think DHD, and perhaps myself
got caught up on the "load or store" which probably means only
register->memory (memory->register too) and not register->register.

I'll rewrite this patch to do an fldd and see what the tests say. I'm
toatally under the assumption that this operation doesn't need to be
optimal :) (e.g. If you use feraiseexcept a lot you are not a
high-performance program).

c.

Re: [parisc-linux] Re: [glibc] fixing delayed exceptions in hppa

[John David Anglin]

> On Fri, Aug 22, 2003 at 04:24:19PM -0400, John David Anglin wrote:
> > Based on what Jim Hull said, I believe that would be better.  I was using
> > 
> >   "fldd 0(%%sr0,%%sp),%0" : "=f" (d) : "0" (d)
> > 
> > There isn't a true dependency in the above but I believe that any load
> > to the destination register will raise the exception.
> 
> Dave, I'm sorry if you sent me a patch and I dropped it :( Did I ever
> receive a diff for this from you?

I can't recall but I probably did send it last November.  My email
machine is still down because of the blackout.

> It's rather vague at times because the spec says "or an operation which
> depends on a pending, trapping insn." I think DHD, and perhaps myself
> got caught up on the "load or store" which probably means only
> register->memory (memory->register too) and not register->register.

Yes.  If you follow the thread that I sent you, Jim Hull comments on
this and offers a rewrite of the sentence that you quoted.  I believe
that referencing memory is important as this makes the operation visible
to another processor.  A register->register operation doesn't do this.

Dave

Re: [parisc-linux] Re: [glibc] fixing delayed exceptions in hppa

[Carlos O'Donell]

> 
> Yes.  If you follow the thread that I sent you, Jim Hull comments on
> this and offers a rewrite of the sentence that you quoted.  I believe
> that referencing memory is important as this makes the operation visible
> to another processor.  A register->register operation doesn't do this.
> 

I implemented and tested 3 versions, fcpy doesn't work on my c3k, but
the fstd and fldd does. Any recommendations on which to take. I'm
tempted to leave all this in and send the patch like this upstream, so I
don't forget what the other versions looked like :)

Comments welcome.

c.


diff -u -p -r1.4 fraiseexcpt.c
--- libc/sysdeps/hppa/fpu/fraiseexcpt.c	10 Sep 2002 01:26:37 -0000	1.4
+++ libc/sysdeps/hppa/fpu/fraiseexcpt.c	30 Aug 2003 16:35:48 -0000
@@ -22,9 +22,27 @@
 #include <float.h>
 #include <math.h>
 
+/* We implement three methods for flushing delayed exceptions. The first
+   is an interlocked register copy with the destination register of the 
+   trapping insn. This method is not recommended, and may not work in all
+   situations. The last two, either loading or storing a value from memory
+   into the destination register of the trapping insn will work, here we
+   choose to store the value to memory.
+  
+   Please see section 10, 
+   page 10-5 "Delayed Trapping" in the PA-RISC 2.0 Architecture manual */
+
+#undef BARRIER_FCPY
+#define BARRIER_FSTD
+#undef BARRIER_FLDD
+
 int
 feraiseexcept (int excepts)
 {
+  /* Provides a place to fake our write for flushing the delayed trap */
+   double dmem = 0;
+   double * pmem = &dmem;
+	
   /* Raise exceptions represented by EXCEPTS.  But we must raise only one
      signal at a time.  It is important that if the overflow/underflow
      exception and the divide by zero exception are given at the same
@@ -33,26 +51,49 @@ feraiseexcept (int excepts)
 
   /* We do these bits in assembly to be certain GCC doesn't optimize
      away something important, and so we can force delayed traps to
-     occur.  */
-
-  /* FIXME: These all need verification! */
+     occur. */
 
   /* First: invalid exception.  */
   if (excepts & FE_INVALID)
     {
       /* One example of a invalid operation is 0 * Infinity.  */
       double d = HUGE_VAL;
-      __asm__ __volatile__ ("fmpy,dbl %1,%%fr0,%0\n\t"
-			    /* FIXME: is this a proper trap barrier? */
-			    "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d));
+      __asm__ __volatile__ (
+		"	fmpy,dbl %0,%%fr0,%0\n"
+#ifdef BARRIER_FCPY
+		"	fcpy,dbl %0,%1"
+		: "+f" (d), "=f" (dmem)
+#endif
+#ifdef BARRIER_FSTD
+		"	fstd,dbl %0,%1"
+		: "+f" (d), "=m" (*pmem)
+#endif
+#ifdef BARRIER_FLDD
+		"	fldd,dbl 0(%%sr0,%%sp),%0"
+		: "+f" (d)
+#endif
+	);
     }
 
   /* Next: division by zero.  */
   if (excepts & FE_DIVBYZERO)
     {
       double d = 1.0;
-      __asm__ __volatile__ ("fdiv,dbl %1,%%fr0,%0\n\t"
-			    "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d));
+      __asm__ __volatile__ (
+		"	fdiv,dbl %0,%%fr0,%0\n"
+#ifdef BARRIER_FCPY		
+		"	fcpy,dbl %0,%1"
+		: "+f" (d), "=f" (dmem)
+#endif
+#ifdef BARRIER_FSTD
+		"	fstd,dbl %0,%1"
+		: "+f" (d), "=m" (*pmem)
+#endif
+#ifdef BARRIER_FLDD
+		"	fldd,dbl 0(%%sr0,%%sp),%0"
+		: "+f" (d)
+#endif		
+	);
     }
 
   /* Next: overflow.  */
@@ -61,8 +102,21 @@ feraiseexcept (int excepts)
     {
       double d = DBL_MAX;
 
-      __asm__ __volatile__ ("fmpy,dbl %1,%1,%0\n\t"
-			    "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d));
+      __asm__ __volatile__ (
+		"	fmpy,dbl %0,%0,%0\n"
+#ifdef BARRIER_FCPY		
+		"	fcpy,dbl %0,%1"
+		: "+f" (d), "=f" (dmem)
+#endif
+#ifdef BARRIER_FSTD
+		"	fstd,dbl %0,%1"
+		: "+f" (d), "=m" (*pmem)
+#endif
+#ifdef BARRIER_FLDD
+		"	fldd,dbl 0(%%sr0,%%sp),%0"
+		: "+f" (d)
+#endif		
+	);
     }
 
   /* Next: underflow.  */
@@ -71,8 +125,23 @@ feraiseexcept (int excepts)
       double d = DBL_MIN;
       double e = 69.69;
 
-      __asm__ __volatile__ ("fdiv,dbl %1,%2,%0\n\t"
-			    "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d), "f" (e));
+      __asm__ __volatile__ (
+#ifdef BARRIER_FCPY		
+		"	fdiv,dbl %0,%2,%0\n"
+		"	fcpy,dbl %0,%1"
+		: "+f" (d), "=f" (dmem) : "f" (e)
+#endif
+#ifdef BARRIER_FSTD
+		"	fdiv,dbl %0,%2,%0\n"
+		"	fstd,dbl %0,%1"
+		: "+f" (d), "=m" (*pmem) : "f" (e)
+#endif
+#ifdef BARRIER_FLDD
+		"	fdiv,dbl %0,%1,%0\n"
+		"	fldd,dbl 0(%%sr0,%%sp),%0"
+		: "+f" (d) : "f" (e)
+#endif		
+	);
     }
 
   /* Last: inexact.  */
@@ -81,8 +150,23 @@ feraiseexcept (int excepts)
       double d = 1.0;
       double e = M_PI;
 
-      __asm__ __volatile__ ("fdiv,dbl %1,%2,%0\n\t"
-			    "fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0" (d), "f" (e));
+      __asm__ __volatile__ (
+#ifdef BARRIER_FCPY		
+		"	fdiv,dbl %0,%2,%0\n"
+		"	fcpy,dbl %0,%1"
+		: "+f" (d), "=f" (dmem) : "f" (e)
+#endif
+#ifdef BARRIER_FSTD
+		"	fdiv,dbl %0,%2,%0\n"
+		"	fstd,dbl %0,%1"
+		: "+f" (d), "=m" (*pmem) : "f" (e)
+#endif
+#ifdef BARRIER_FLDD
+		"	fdiv,dbl %0,%1,%0\n"
+		"	fldd,dbl 0(%%sr0,%%sp),%0"
+		: "+f" (d) : "f" (e)
+#endif		
+	);
     }
 
   /* Success.  */

Re: [parisc-linux] Re: [glibc] fixing delayed exceptions in hppa

[John David Anglin]

> > Yes.  If you follow the thread that I sent you, Jim Hull comments on
> > this and offers a rewrite of the sentence that you quoted.  I believe
> > that referencing memory is important as this makes the operation visible
> > to another processor.  A register->register operation doesn't do this.
> > 
> 
> I implemented and tested 3 versions, fcpy doesn't work on my c3k, but
> the fstd and fldd does. Any recommendations on which to take. I'm
> tempted to leave all this in and send the patch like this upstream, so I
> don't forget what the other versions looked like :)

The FSTD barrier looks fine to me.  The fcpy version doesn't work, so
I wouldn't keep it around.  You might add a comment that fcpy doesn't
work on at least some implementations.

Dave