This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][RFC] Remove TODO_ggc_collect, collect unconditionally
- From: Bernd Schmidt <bernds at codesourcery dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: <gcc-patches at gcc dot gnu dot org>, <vmakarov at redhat dot com>
- Date: Thu, 11 Apr 2013 12:12:01 +0200
- Subject: Re: [PATCH][RFC] Remove TODO_ggc_collect, collect unconditionally
- References: <alpine dot LNX dot 2 dot 00 dot 1303191327310 dot 3543 at zhemvz dot fhfr dot qr> <alpine dot LNX dot 2 dot 00 dot 1303191518000 dot 3543 at zhemvz dot fhfr dot qr> <alpine dot LNX dot 2 dot 00 dot 1303191634460 dot 3543 at zhemvz dot fhfr dot qr> <5166888E dot 3080906 at codesourcery dot com> <alpine dot LNX dot 2 dot 00 dot 1304111201470 dot 21094 at zhemvz dot fhfr dot qr>
On 04/11/2013 12:05 PM, Richard Biener wrote:
> Any particular suggestions? The easiest "split" is to emit
> a '================ reload/lra =============' marker (or similar).
It's about getting a dump of the insns, in two separate files so that
one can do diffs (between sched1/ira or ira/reload).
> Another possibility is to try making the IRA/reload/LRA boundary
> GC safe (I didn't even try to see what is missing). As other
> people noted that they are two distinct "passes" is an artifact
> as the IL "between" them is in no useful form (you can't insert
> any other pass inbetween). Another possibility is to somehow
> teach the dump machinery to allow switching to an alternate
> I'm for whatever is the least work for me, and a single dumpfile
> doesn't sound bad to me if the two pieces can be easily identified
> (look for example at the 000i.cgraph dump, or IPA pass dumps in general).
Why do we need to remove TODO_ggc_collect anyway? I think a straight
revert is the simplest solution.