what optimizations are invalid in java?

[Andrew Haley]

Jan Hubicka writes:
 > > >>>>> "Jan" == Jan Hubicka <jh@suse.cz> writes:
 > > 
 > > Jan> thinking more about Java and exceptions, can someone who
 > > Jan> understand standard better than I do comment what transfromations
 > > Jan> are valid and what invalid:
 > > 
 > > Jan> fold_const: We can remove dead parts of expresisons poossibly eliminating
 > > Jan>    trap.
 > > 
 > > If they are dead then they can't be executed, correct?
 > 
 > Code not executed is unreachable, dead code is code executed but with void
 > results.  In fold const we can delete as dead for instance (a/b)*0 that may
 > trap in case b is 0.
 > 
 > Does Java trap only in division-by-zero case, or also in the overflow in
 > signed arithmetics?

Only divide by zero.  Basically, Java does whatever SPARC UNIX
happened to do at the time.  This is not, I suspect, a coincidence...

 > > In that case no trap could occur.
 > > 
 > > Jan> cleanup_cfg: We may eliminate fp comparison that traps in case the associated
 > > Jan>      branch is not needed.
 > > 
 > > Floating point operations never result in traps in Java.
 > 
 > This is very good. Do we implement it?  I am pretty sure that currently
 > we do add EH edges to each FP operation.  This is anoying especially for
 > FP conditional branches, where CFG code is no longer able to recognize
 > simple conditional in it.

That's annoying.

 > I was thinking about revisiting the code and adding some abstraction around,
 > but if we can just kill the EH edge, it is much better sollution.
 > 
 > This means that java on each supported architecture is using some startup
 > code to mask FP exceptions?  (or that should be done).

I've only ever seen one machine where FP exceptions caused traps.
This property breaks many C programs as well, of course.

Andrew.