This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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~