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: [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~



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