Re: CFG and libcall conflict for java

[Jim Wilson <wilson at cygnus dot com>]

>Does Java standard require the trap to happen?

Alex answered that one.  I knew about the divide by zero, but wasn't aware
that this only mattered for integer divides, and that this was the only case.

>I believe correct way is to emit those divides as normal calls, not libcalls,
>as libcalls are not allowed to throw nor span the basic block boundary.

I have a patch written by Hans Boehm that does that.  It supresses the
REG_LIBCALL/REG_RETVAL notes when the call can throw.  It tests
flag_non_call_exceptions and may_trap_p to make the decision.

>Can they really throw?  (ie the sofware emulation creates some trap when division
>overflows?)

I haven't checked this yet.  My assumption is that the java compiler
installs a signal handler that catches the appropriate signal and then
calls throw to generate an language-level exception.  This also assumes
that throw works through the signal handler.  We may not have all of this
working yet, but it will have to work in order to handle the integer divide
by zero case.

As for the IA-64, the divide sequence used starts with a reciprocal
approximation instruction, and ends with a round.  It is designed by
Intel to set all the same IEEE flags that a divide instruction would set,
and generate all the same signals.  So yes, we should get a divide by
zero trap, and then a SIGFPE (or whatever) signal.  Unless perhaps we are
getting a NaN, in which case all of this is pretty pointless.  I should check
this.

>With midlevel RTL/AST branch we should be able to optimize still well enought,
>as the DCE will be done earlier.

>Richard, what do you think?

I talked to Richard a little bit.  He didn't think hacking up the cfg code
was a good idea.

So it does seem that the most reasonable solution here is to stop treating
divides as libcalls when flag_non_call_exceptions.  We lose a little
performance, but it only affects java at the moment, and we will get the
performance back later when we have ast and/or midlevel RTL optimizations.

Jim