This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Don't eliminate insns that may trap
Jan Hubicka writes:
> > Richard Henderson writes:
> > > On Mon, Sep 30, 2002 at 06:46:07PM +0100, Andrew Haley wrote:
> > > > * flow.c (insn_dead_p): When using non-call-exceptions, don't
> > > > eliminate insns that may trap.
> > > > * cse.c (insn_live_p): Likewise.
> > >
> > > I'm not really fond of this, but I guess it's the
> > > best we can do
> >
> > This seems to be the response to many of my patches... :-)
>
> Perhaps this should be controlled by separate flag, like
> -fhonnor-exceptions or something like that.
I don't think that this would be a good idea, unless someone comes up
with an application or programming language that actually requires it.
Java says two things:
1. Null pointer exceptions may be caught
2. Null pointer accesses will always generate null pointer exceptions
Unless there is a language in which 1 holds but 2 does not, we'd be
providing an option that no-one will actually use.
> Except for removing insns that may trap we also need to disable some
> algebraic simplifications (like noticing that x*0 can be elliminated)
> and friends.
I applied a couple of patches to remove algebraic simplification of
trapping division a couple of years ago. There may well be cases that
remain.
It's important to be realistic here: I'm not interested in every
possible insn that might trap on a weird machine, but the ones that
actually do: memory access and division by zero.
Andrew.