Re: May delete_trivially_dead_insns delete trapping insns?

[Andrew Haley <aph at redhat dot com>]

Michael Matz writes:
 > Hi,
 > 
 > On Fri, 22 Nov 2002, Jan Hubicka wrote:
 > 
 > > It uses delete_insn_and_edges to remove the insns.
 > 
 > Hmm, right, I overlooked that.
 > 
 > > > Why for Java, but not for other languages?  If there are no
 > > > trapping insns
 > >
 > > Because Java requires all exceptions to happen.  So you can't remove
 > > dead insns that possibly trap.
 > 
 > Ok, then a patch is needed to prohibit that.  Will do that when I'm in
 > prague ;-)

We have in the past conditionalized such things on
flag_non_call_exceptions, but a recent discussion about Ada suggests
that isn't always right.  As I understand it, Ada requires a trap for
null pointer accesses but allows insns that read data that is never
used to be deleted.  I reluctantly suggest that perhaps we need
another flag.

 > > Can you take a look why delete_insn_and_edges didn't removed the
 > > edge?
 > 
 > It is possible that I confused it with some other place deleting the insn
 > (I had a local patch prohibiting deleting trapping insns, got an error,
 > removed the patch, got a different error, and before patching any further
 > I wanted to clarify the semantics on the list ;) ).  For instance
 > reg-stack.c also uses bare delete_insn() (without checking trapping btw.)
 > but in the end calls fixup_abnormal_edges().  The latter becomes mightyly
 > confused if it finds exception edges but no trapping insns.
 > 
 > I wonder if for sanity-checking we should include a abort() in
 > delete_insn(), which triggers, if
 >   (flag_non_call_exceptions && may_trap_p())
 > I bet it will trigger quite often for Java programs.  OTOH I'm not sure
 > enough about Java semantics to know if the above really is disallowed.

What about the case when we know an insn is unreachable?

Andrew.