This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: sjlj exceptions
- To: law at redhat dot com
- Subject: Re: PATCH: sjlj exceptions
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Date: Tue, 5 Dec 2000 23:32:06 -0500 (EST)
- Cc: gcc-patches at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org
> In message <200010272021.QAA08569@hiauly1.hia.nrc.ca>you write:
> > This patch resolves to some extent the problems noted in these two postings
> > :
> > <http://gcc.gnu.org/ml/gcc-bugs/2000-08/msg00687.html> and
> > <http://gcc.gnu.org/ml/gcc-bugs/2000-10/msg00083.html>. My investigation
> > revealed that the problem is only present when sjlj exceptions are used.
> > The memory expansion occured in the gcse pass and was a result of the
> > large number of edges present in functions using sjlj exceptions.
> I believe if you look at Richard's recent changes to the SJLJ exception
> handling code you'll find that we now build a better CFG (specifically we
> don't have nearly as many useless edges).
>
> For a testcase I'm dealing with right now it's drastically reduced both the
> memory requirements and compile times. To give you some idea, the test
> takes > 40 minutes to compile without the patch and > 200M of memory
> (I didn't bother waiting for it to complete, so I have no idea how long
> it would take to finish or whether or not the peak memory usage would
> increase). After Richard's patch we're on the order of 7 minutes and
> 100M of memory.
>
> There is one bug introduced by Richard's patch that I'll post a fix for
> shortly.
This is great news. However, it appears that gcse_main still punts when
current_function_calls_setjmp. The function expand_builtin_setjmp_setup
sets this, so I think the memory reduction might be due to the gcse pass
being disabled.
I had seen failures in the bb reorder pass both with and without
DONT_USE_BUILTIN_SETJMP defined. The failures when it is defined are
more common. However, I found a failure when it was not defined
building groff. In both cases, the reordering caused NOTE_INSN_EH_REGION_END
notes to be placed before the corresponding NOTE_INSN_EH_REGION_BEG note.
It will be interesting to see if the new changes fix the problem.
resolve the problem that
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)