Re: thread-safe exceptions (first cut)

[mrs at wrs dot com (Mike Stump)]

> Date: Fri, 12 Sep 1997 01:35:01 -0500 (CDT)
> From: scott snyder <snyder@d0sgif.fnal.gov>
> To: egcs@cygnus.com

Great work, thanks for the help.  I'll give you (or others that can
work on it) some ideas on where next this can go.  I won't be working
on this for a little while yet (> 1 month).

> Here are a couple notes on what i did:

>  - I replaced references to __eh_pc with a call to a new library
>    function __get_saved_pc, which works like __get_dynamic_handler_chain.

All these should be collapsed into just one routine.  We get a pointer
to a structure, that has at the front of it, the backend data
structures, and the end, we store the frontend extra data structures.

>    In fact, perhaps these two should be merged into one routine.

Yes.

>  - I replaced the four C++-specific EH variables with a call to
>    a new library function __get_cpp_eh_context, which returns
>    a pointer to a structure.  In principle, this could be merged
>    with __get_saved_pc as well,

Yes.

>    but it seemed like a good idea to keep the language-dependent
>    part separate from the part which is supposed to be
>    language-independent.

I don't think it is worth it to separate them too far.
EXCEPTION_LANG_SPECIFIC seems to match the existing philosophy quite
well.  What do others think?

>    Since this is in the front end, calls to __get_saved_pc can be
>    generated by building tree structures.  Here, i was able to
>    simply turn on TREE_READONLY, and i found that multiple calls to
>    __get_saved_pc got CSE'd away when i turned on optimization.

Hum, I tried to get CSE to eliminate them, but it didn't.

>    (Perhaps something similar can be done for __get_saved_pc and
>    __get_dynamic_handler_chain?  It looks like what's missing is
>    that they need to have a LIBCALL block?)

I did a LIBCALL block for them, maybe I didn't try hard enough.  I
came up with a new idea, and that was to use a pseudo on them, and
setup the pseudo at the front of the function.  The hard part is one
has to add in more logic for inlining, unless a fixed pseudo can be
used.  It has the benefit of awesome code, even if -O isn't used, and
making the optimizer have to do less.

Oh, one has to be careful to watch for thread creation calls, and not
cache the returned pointer across them.  I thought it would be easier
to manage this with the pseudo code, rather than the cse code.

I haven't reviewed the patches...  I won't be able to until next week
or so.


Thanks.