Re: [PATCH] Java: expand divide, expand conversions

[Andrew Haley <aph@pasanda.cygnus.co.uk>]

> From: Alexandre Oliva <oliva@dcc.unicamp.br>
> Date: 20 Jul 1999 14:59:55 -0300
> 
> On Jul 19, 1999, Andrew Haley <aph@pasanda.cygnus.co.uk> wrote:
> 
> >> From: Tom Tromey <tromey@cygnus.com>
> 
> Andrew> I have not yet appplied this patch.  Comments welcome.
> 
> >> Would it be hard to inline the test for divide-by-0?  
> 
> > I could easily do that, but it would result in evil code bloat.
> 
> According to well-informed sources, it is probably worth the bloat,
> except when optimizing for space.

Perhaps.  However, most UNIX systems should be able to catch the
divide by zero trap, so the option of calling a subroutine to do the
division probably applies only to embedded targets.

The divide subroutine is also a temporary measure for UNIX targets
which haven't yest had the signal handling code ported.

> We have recently had a discussion about removing some code bloat
> introduced by pointer-to-member-functions handling in C++, by using
> thunks to avoid a test about the kind of pointer-to-member.  The
> outcome was the it would be much worse in terms of speed; modern
> processors handle conditional branches much more efficiently than
> function calls, even if the call is to a thunk that will just adjust
> some register and call a target function.  Now think of the overhead
> of a complete function call!

True: however, it's a function call to a routine with a division and
two tests and conditional branches.  I'm failing to imagine a target
which can't trap the division by zero and doesn't mind the bloat.  I'm
not convinced that calling the subroutine only when using -Ospace
makes sense.

Andrew.