This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix sched-ebb.c bug (was Re: [3.3 branch] IA64bootstrap failure)
- From: Jim Wilson <wilson at tuliptree dot org>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Vladimir Makarov <vmakarov at redhat dot com>, Bernd Schmidt <bernds at redhat dot com>, "H. J. Lu" <hjl at lucon dot org>, Andreas Schwab <schwab at suse dot de>, gcc-patches at gcc dot gnu dot org
- Date: 15 Jul 2003 16:51:47 -0700
- Subject: Re: [PATCH] Fix sched-ebb.c bug (was Re: [3.3 branch] IA64bootstrap failure)
- References: <je4r1xuq2i.fsf@sykes.suse.de><200307081526.26404.ebotcazou@libertysurf.fr><jeel11t8h2.fsf@sykes.suse.de> <20030708143705.GA13718@lucon.org><jewuetrs9m.fsf@sykes.suse.de> <3F0B4B72.5080802@tuliptree.org><20030709152453.GA3682@lucon.org><20030709163759.GB20507@sunsite.ms.mff.cuni.cz><20030709233503.GC20507@sunsite.ms.mff.cuni.cz><1057815303.1019.0.camel@leaf.tuliptree.org> <20030715211255.GS20507@sunsite.ms.mff.cuni.cz>
On Tue, 2003-07-15 at 14:12, Jakub Jelinek wrote:
> Now, are those memory consumptions unacceptable (for 3.3, or for mainline)?
That looks like a noticeable amount of memory in the worst case, but not
a problem in the normal case, so I think we can live with that for now
to fix a bootstrap problem.
> If yes, is it ok if we get rid of them just on 64-bit hosts (sched-ebb.c
> is by default used AFAIK on IA-64 target, so that would save memory during
> IA-64 native compilations)?
I don't like that choice. We should fix the problem everywhere if we
fix it at all.
> Also, do we want to refcount the cselib_subst_to_values'ed cselib_val's
> (which would mean tracking where we release last references to them),
> or just flag them as never useless when cselib_subst_to_values is called
> and only free them at cselib_finish time?
recounting seems like a bit of trouble, but would be good if it isn't
too hard to get working.
Freeing them at cselib_finish_time seems reasonable. The current code
incidentally doesn't try to free the values. Apparently it relies on GC
to free them but there is no ggc_collect call during sched, so we should
try to free them ourselves.
> * cselib.c (cselib_subst_to_values_1): Renamed from
> cselib_subst_to_values.
The patch seems reasonable to me if it works. It is lacking comments
explaining why we are doing this though. There should be a comment for
cselib_subst_to_values saying that it should only be called from outside
cselib, and there should be a comment pointing out that we can't free
apparently unused values during cselib if cselib_subst_to_values was
called, because then we end up with dangling pointers outside cselib.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com