This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFC] Remove TODO_ggc_collect, collect unconditionally
- From: Richard Biener <rguenther at suse dot de>
- To: Bernd Schmidt <bernds at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, vmakarov at redhat dot com
- Date: Thu, 11 Apr 2013 12:26:00 +0200 (CEST)
- 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> <51668C71 dot 2090004 at codesourcery dot com>
On Thu, 11 Apr 2013, Bernd Schmidt wrote:
> 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
> > dumpfile.
> >
> > 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.
The point was not to remove TODO_ggc_collect, the point was to
both enforce the GC boundary at all passes (that's what the pass
manager assumes anyway) and to collect when necessary at such
well-defined boundaries. Another approach would have been to
add TODO_ggc_collect everywhere where it wasn't.
Note that pending patches will similarly enforce a verification
of all IL properties that are seemingly active. Thus it will
remove stuff like TODO_verify_flow_info and verify that always
between passes if there is a CFG. I routinely discover
verification issues in unrelated passes because verify TODOs
are missing in a lot of places. I'm quite sure that IL
verification between IRA and reload will not work (it doesn't
for loop verification at least - one reason I throw away
loop info after RTL loop opts ...)
So, the option I didn't mention is to add a way to disable the
GC (clearing/setting a property for example).
Richard.