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: [tree-ssa] Avoiding double simplification


On Tue, Mar 11, 2003 at 08:22:13AM -0700, law at redhat dot com wrote:
> That's roughly what I had in mind.  Implementation difficulties may (of
> course) change this.  Can op1 reach any target that op0 can not reach?
> [ ie, can op1 throw or goto to some outer context? ]

Yes.

> OK.  So how can I identify the statements which may throw within op0?

Look at TREE_NOTHROW.  At present this is documented only on
CALL_EXPR and FUNCTION_DECL, but when flag_noncall_exceptions
is enabled, we'll want to look at this for memories as well.
(Java has a good notion of a lot of memories that can't trap.)

> Hmm, I thought this stuff nested -- ie, there was one and only one catch
> point for any particular call.  If that particular handler didn't catch
> the throw, then it punted to a parent handler.  But that's just my memory
> of how I thought this stuff worked.

This is no longer the case.  The EH tables carry a lot more 
information now.  We only transfer to a handler when we know
that it is supposed to handle it.

> OK, maybe this was the "nesting" I vaguely referred to above.  

If you last looked at this stuff before 3.0, it did work like
you remember.  The CLEANUP bit Jason was just describing is
a bit different -- there is no test there to see whether or
not the code needs to run.  It's a cleanup, so it _always_
needs to run.


r~


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