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

[Richard Sandiford <rsandifo at redhat dot com>]

cgd@broadcom.com writes:
> And down the rabbit hole we go...

Sorry for the split reply.  Didn't see this bit...

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

Yeah, well, there's so many cross-references in the comments that
it's very difficult to keep everything up to date.  I'm in the
process of going through them at the moment.

Although I should have grepped for div_trap when I removed it.
Sorry about that.

> 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?

See the default definition of the length attribute.

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

Agreed that this feature might be useful.  But no-one's been sufficiently
motivated to add it.

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

It was ripped out because it didn't work and no-one apparently noticed.
See: http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00703.html

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

See above message for rationale.

> So, it looks like for one testsuite failure we've found that:
> 
> * instruction predicates not optimal.
> 
> * instruction constraints not optimal.

For one instruction (which, since your message seems to be somewhat
critical of the rewrite, was around long before that started ;).

> * comments/documentation wrong.

Lots of comments in the mips port are wrong.  See my recent patch
that tried to clean up those in mips.c and mips.h.  Some of those
had been around for years and been out of data for years.

> Can we go deeper?  8-)

Well, what did you expect? ;)  It was this sort of thing that motivated
the rewrite in the first place.  And the rewrite isn't done yet.  It's
just a case of finding time in which to do it.

Richard