May delete_trivially_dead_insns delete trapping insns?

Andrew Haley aph@redhat.com
Mon Nov 25 06:16:00 GMT 2002


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.



More information about the Gcc mailing list