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.
