This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: gcj non-optimization curiosity
- From: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- To: tromey at redhat dot com
- Cc: java at gcc dot gnu dot org
- Date: Mon, 17 Dec 2001 12:22:59 +1300
- Subject: Re: gcj non-optimization curiosity
- References: <87vgf628c4.fsf@creche.redhat.com>
Tom Tromey wrote:
>L16 is the call to throw a null pointer exception (a non-returning
>call), and L18 is the call to throw a bad array index exception
>(another non-returning call).
>
>There are a few things I don't understand about this code that I would
>like to understand.
>
I'm a bit concerned about the high cost of bounds checks too. It used to
be that --no-bounds-check made a modest improvement to performance, but
with the current compiler the difference is huge in some cases. Some
code runs twice as fast with --no-bounds-check now.
>* Why isn't the null-pointer check hoisted out of the loop?
> We know `foo' doesn't change during the loop, so this would be safe.
>
>* Why is the length of the array ("movl 4(%eax), %edx") re-loaded each
> time through the loop?
>
I've noticed this too and it is strange. I have a vague suspicion that
the use of SAVE_EXPR to force the bounds check to occur at the right
time may be inhibiting the compilers ability to optimize them properly.
regards
Bryce.