This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [rfc] exception handling in gimple
On 09/08/2009 07:33 AM, Michael Matz wrote:
I haven't read nearly all of it yet, but one thing I noticed. You
introduce some new predicates (which is wonderful :) ), and use them in
some places where it's not immediately clear they're equivalent:
--- a/gcc/dce.c
+++ b/gcc/dce.c
@@ -81,10 +81,8 @@ deletable_insn_p_1 (rtx body)
default:
if (volatile_refs_p (body))
return false;
-
- if (flag_non_call_exceptions&& may_trap_p (body))
+ if (insn_could_throw_p (body))
return false;
You're right that this one isn't equivalent; I had already found
that bug and moved the insn_could_throw_p check to deleteable_insn_p.
- || (flag_non_call_exceptions&& may_trap_p (PATTERN (insn)))
+ || insn_could_throw_p (insn)
(at least cse.c has a similar hunk)
Your new insn_could_throw_p() always returns true for calls, no matter if
they possibly are marked as nothrow, or are pure/const. I think this
pessimizes the above hunks (though I haven't checked the surroundings).
Further, insn_could_throw_p() takes a full instruction, not a pattern, but
at least in the first hunk you have the pattern already.
Yes, insn_could_throw_p, like stmt_could_throw_p, is supposed to
disregard the on-the-side EH information (in this case REG_EH_REGION)
so that we can tell if the on-the-side EH information is necessary.
You're probably right that DSE could use the insn_nothrow_p predicate
instead. However, I wanted to make the transformations as close to
direct as possible. In some instances, like CSE, the pass isn't
prepared to deal with REG_EH_REGION notes at all. So the fact that
a call is const, and therefore nothrow, doesn't really help since
there's still a REG_EH_REGION 0 note to deal with.
A general remark: The exception machinery and how it's implemented always
sorely lacked high level internal documentation. E.g. what exactly is in
struct eh_landing_pad_d.post_landing_pad vs .landing_pad, and similar, how
are the high level language constructs implemented with the different
eh-tree nodes (what's e.g. EH_FILTER and how does it relate to
try/catch/throw, and so on), . I somewhat hoped an exception rewrite
would add something enlightening from the author of also the older
exception stuff so I can wrap my little mind around it more easily. In
the past I always figured out what is supposed to be doing what, but I
forget after a few months and always have to relearn the ugly details by
browsing sources instead of comments :)
I did add a page or two of documentation about the EH lowering process
and the 99 passes that seem to be involved. But I can certainly add
more that describe the data structures.
I'll finish up some varray to vec conversion I'm in the middle of,
add those docs, and get a revised patch out tonight.
r~