[mips patch RFA] handle trap_if with DI-mode arguments.

[cgd@broadcom.com]

At 13 Aug 2003 23:06:49 +0100, Richard Sandiford wrote:
> > And the nonmemory_operand -> arith_operand change should (possibly
> > ever so slightly) help the performance of the compiler, one would
> > hope?
> 
> Yeah.  mips_gen_conditional_trap makes sure that the second operand
> is within range.  But with nonmemory_operand, combine might turn:
> 
>     r1 = 0x12345
>     trap_if r2 = r1
> 
> into:
> 
>     trap_if r2 = 0x12345

why would it do that?

i mean, it it just "because it can, and because the predicates don't
prevent it from doing so?"  (the constraints coming into play at a
different time?)



And down the rabbit hole we go...


;; 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.

AFAICT, there **are** no "div_trap_*" insns, and there won't be any
trap_if's with args 6 or 7...  (looks like a comment issue; the
comments weren't updated with the rewrite.  8-)


it looks like mips_output_division directly generates division and
additional branch/break if necessary.  but the things that invoke
mips_output_division don't seem to indicate a proper length, do they?


and it looks liks mips_output_divison will *never* attempt to use
conditional-trap instructions to do the trapping.  (it can be more
efficient to use condtrap than branch/break, if it's OK with the user.
See the assembler's -trap flag, of course.)


And it looks like nothing ever tries to check for division/remainder
overflows at all... but it looks like this was ripped out
intentionally.  Presumably nobody was using the (MD) option that
enabled it?  (I assume that if language semantics require checks,
those are implemented by the languages... but i wonder, those probably
wouldn't preserve the MIPS convention of divide by 0 -> break/trap
code 6, overflow -> break/trap code 7, would they...  I think that's a
"whatever!!" though.)


Why not represent the break/trap generation in RTL, as it appears used
to be done?  Too hard to keep track of things to make sure the
traps/breaks show up in the right place?  or...?



So, it looks like for one testsuite failure we've found that:

* instruction predicates not optimal.

* instruction constraints not optimal.

* comments/documentation wrong.

* instruction size wrong.

* gcc never attempts to generate (desirable) conditional trap
  instructions (instead of branch/break).


Can we go deeper?  8-)



cgd