Re: what optimizations are invalid in java?

[Jan Hubicka <jh at suse dot cz>]

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

Unless I am mistaken, Windows and FreeBSD does not mask fp exceptions.
I remember it because my fractal zoomer has been crashing on these, so I guess
at least for such targets we need to preload some code.
On i386 the FP comparisons never trap anyway, as we always use nontrapping
instructions.  Perhaps we should invent some way to let backend know about
such property and default it for Java.

Honza
> 
> Andrew.