Re: [patch] Use FPU for integer division on Alpha

[Richard Henderson <rth at redhat dot com>]

On Sun, Mar 20, 2005 at 01:03:24PM +0100, Falk Hueffner wrote:
> It would be helpful if you could say why.

Because I don't like the idea of the signal being delivered to a
calling function, for instance.

> But just as a shortcut, what
> would you say about the patch with divc defined like this:
> 
> (define_insn "divc"
>   [(set (match_operand:DF 0 "register_operand" "=&f")
> 	(unspec:DF [(match_operand:DF 1 "reg_or_0_operand" "fG")
> 		    (match_operand:DF 2 "reg_or_0_operand" "fG")] UNSPEC_DIVC))]
>   "TARGET_FP"
>   "div%-%/ %R1,%R2,%0"
>   [(set_attr "type" "fdiv")
>    (set_attr "trap" "yes")	
>    (set_attr "round_suffix" "c")
>    (set_attr "trap_suffix" "u_su_sui")])

I don't think we ever want a trap suffix for the integer division.

Hmm, something to check:

#include <fenv.h>
#include <setjmp.h>

volatile int x = 1, y = 0;
jmp_buf buf;

int foo()
{
  return x / y;
}

void handler(int sig)
{
  longjmp (buf, 1);
}

int main()
{
  signal (SIGFPE, handler);

  feclearexcept (FE_DIVBYZERO);
  if (setjmp (buf) == 0)
    foo();
  if (fegetexcept () & FE_DIVBYZERO)
    abort ();

  fedisableexcept (FE_DIVBYZERO);
  if (setjmp (buf) == 0)
    {
      foo ();
      abort ();
    }

  return 0;
}

I think this test should pass.  Unfortunately, this even fails with
the current implementation, because the kernel seems to be surpressing
the signal from the gentrap -- for no explicable reason.

I *hope* that not setting /s will mean that ev6 will trap even with
FPCR_DZED set, but I wouldn't count on it.  Undefined or not, I think
we'd have a poor implementation if we failed to generate a signal on
integer division by zero.

Further, we definitely do *not* want /sui, since that would set FPCR_INE
when computing 1 / 3, which does not have the div-by-zero advantage of
being undefined and thus allowing us all sorts of other side effects.


r~