Re: another compiler better than gcj ?

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Anthony Green wrote:

>Bryce wrote:
>
>>Yeah. The Sieve.java case is most interesting because its just a loop
>>with no allocation, no type checks, etc, so in theory the Java code
>>should be just as fast as a C equivilant if you use --no-bounds-checks.
>>
>
>I looked at another sieve routine (in Primes.java), and it does things like
>division by two in the inner loop.  On x86 Linux we currently emit calls to
>_Jv_divI when we could safely just emit a shift insn.  I'm running make check
>right now with a patch to help improve this.
>

There's no integer divides in Sieve.java so this is not the issue there.

Wouldn't the best solution for x86 integer divides be to just emit 
something like:

if (__builtin_expect (divisor== 0), false)
  _Jv_ThrowDivideByZero()
else
  .. do divide ..

This way the divisor-is-a-constant case will be taken care of 
automatically by constant propogation, it would probibly actually 
generate less code (since multiple uses of the throw call can get 
merged), and be faster in all cases.

regards

Bryce.