This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]