what optimizations are invalid in java?

[Jan Hubicka]

> >>>>> "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?
> 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.

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).

> Integer division and mod are the only arithmetic operators to do this.
> 
> Jan> GCSE: Can we do code motion that reorder traps? I guess not.
> 
> Nope.  Java has fairly strict ordering.  The effects of an assignment
> occurring before such a trap must be visible after the exception is
> thrown.

I think EH edge will prevent GCSE from moving the excperssion, so I guess
it is safe.

I guess we need to fix all places we do dead code removal (not unreachable)
and places that do algebraic simplification that possibly avoids some of
operands from being evaulated.  The second is nasty job :(

Honza
> 
> Tom