MIPS div_trap vs. general conditional traps

MIPS div_trap vs. general conditional traps

[Greg McGary]

I implemented conditional traps for MIPS using the MIPS
conditional-trap machine instructions for ISA>=2 and using the MIPS
`break' instruction for ISA==1.  I posted the patch last night.

Since then, I have noticed that the MIPS div_trap also generates
TRAP_IFs, but always translates them to conditional branches to MIPS
BREAK instructions.  Is there any reason why we shouldn't use
conditional-trap machine instructions for div_trap as well, falling
back to conditional branches to BREAK only for ISA==1 ?

One reason not to do it is that operating systems might expect div
traps to come as BREAKs (EXC == 9), rather than as traps (EXC == 13).
However, since I doubt that OSes do anything other than terminate the
program that gets a div_trap, and BREAK and trap exceptions probably
both terminate just as effectively, it ought not make so much
difference.  The div_trap stuff generates `break 6' (integer divide
overflow) and `break 7' (divide by zero), so the OS probably examines
the offending instruction in order to tailor its response.  Note that
the register/register conditional-trap insns also have a code field,
but at present, gas doesn't accept it.

For backward compatibility, we could always provide a `-m' option to
force branches to BREAKs.

Another reason not to do it, and to favor branches to BREAK even for
general conditional traps is if the conditional-trap machine
instructions are serializing.  My MIPS manuals are silent on that
issue.

Comments?

Greg

Re: MIPS div_trap vs. general conditional traps

[Jeffrey A Law]

  In message < 200009062017.NAA06786@kayak.mcgary.org >you write:
  > I implemented conditional traps for MIPS using the MIPS
  > conditional-trap machine instructions for ISA>=2 and using the MIPS
  > `break' instruction for ISA==1.  I posted the patch last night.
Sounds like a good thing.


  > Since then, I have noticed that the MIPS div_trap also generates
  > TRAP_IFs, but always translates them to conditional branches to MIPS
  > BREAK instructions.  Is there any reason why we shouldn't use
  > conditional-trap machine instructions for div_trap as well, falling
  > back to conditional branches to BREAK only for ISA==1 ?
Because the expansion of division now done by the compiler needed to be
equivalent to what used to be done by the assembler in terms of 
break vs trap.

  > One reason not to do it is that operating systems might expect div
  > traps to come as BREAKs (EXC == 9), rather than as traps (EXC == 13).
Precisely.

  > However, since I doubt that OSes do anything other than terminate the
  > program that gets a div_trap, and BREAK and trap exceptions probably
  > both terminate just as effectively,
You lose the context as to why you had to stop the process.  ie, we use
different break #s for the different reasons why we might stop the
target.

  > For backward compatibility, we could always provide a `-m' option to
  > force branches to BREAKs.
We shouldn't break backwards compatibility to start with.

  > Another reason not to do it, and to favor branches to BREAK even for
  > general conditional traps is if the conditional-trap machine
  > instructions are serializing.  My MIPS manuals are silent on that
  > issue.
No clue on this one.
jeff

Re: MIPS div_trap vs. general conditional traps

[Greg McGary]

Jeffrey A Law <law@cygnus.com> writes:

>   In message < 200009062017.NAA06786@kayak.mcgary.org >you write:
>   > I implemented conditional traps for MIPS using the MIPS
>   > conditional-trap machine instructions for ISA>=2 and using the MIPS
>   > `break' instruction for ISA==1.  I posted the patch last night.
> Sounds like a good thing.

Care to go all the way and review it?  8^)

Here's a newer mips.md that places the general conditional traps
before the div_traps for reasons explained in the comments:

Greg

Index: gcc/config/mips/mips.md
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/mips/mips.md,v
retrieving revision 1.84
retrieving revision 1.81.4.5
diff -u -p -r1.84 -r1.81.4.5
--- mips.md	2000/08/08 22:40:49	1.84
+++ mips.md	2000/09/07 17:12:08	1.81.4.5
@@ -495,7 +495,48 @@
 ;; 
 ;; (define_function_unit "sqrt"     1 1 (and (eq_attr "type" "fsqrt") (eq_attr "mode" "SF"))  54 0)
 ;; (define_function_unit "sqrt"     1 1 (and (eq_attr "type" "fsqrt") (eq_attr "mode" "DF")) 112 0)
+\f
+;;
+;;  ....................
+;;
+;;	CONDITIONAL TRAPS
+;;
+;;  ....................
+;;
 
+(define_insn "trap"
+  [(trap_if (const_int 1) (const_int 0))]
+  ""
+  "*
+{
+  if (ISA_HAS_COND_TRAP)
+    return \"teq\\t$0,$0\";
+  else
+    return \"break\";
+}")
+
+(define_expand "conditional_trap"
+  [(trap_if (match_operator 0 "cmp_op"
+			    [(match_dup 2) (match_dup 3)])
+	    (match_operand 1 "const_int_operand" ""))]
+  "ISA_HAS_COND_TRAP"
+  "
+{
+  mips_gen_conditional_trap (operands);
+  DONE;
+}")
+
+;; Match a TRAP_IF with 2nd arg of 0.  The div_trap_* insns match a
+;; 2nd arg of any CONST_INT, so this insn must appear first.
+;; gen_div_trap always generates TRAP_IF with 2nd arg of 6 or 7.
+
+(define_insn ""
+  [(trap_if (match_operator 0 "trap_cmp_op"
+                            [(match_operand:SI 1 "reg_or_0_operand" "d")
+                             (match_operand:SI 2 "nonmemory_operand" "dI")])
+	    (const_int 0))]
+  "ISA_HAS_COND_TRAP"
+  "t%C0\\t%z1,%z2")
 \f
 ;;
 ;;  ....................