This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFC] Remove TODO_ggc_collect, collect unconditionally

On Thu, 11 Apr 2013, Bernd Schmidt wrote:

> On 03/19/2013 04:37 PM, Richard Biener wrote:
> > On Tue, 19 Mar 2013, Richard Biener wrote:
> >> Which shows that I need to merge the IRA and reload/lra passes.
> >> Honza tells me that they are considered "separate" has historical
> >> reasons only.  Given that reload pushes TV_IRA and that the boundary
> >> isn't GC safe I don't think that is too bad (dump files will now
> >> be shared, of course).
> >>
> >> I'll schedule a gcac checking bootstrap over night as well.
> > 
> > The following is it, changelog omits the boring part (enumerating
> > all files and pass structs touched ...).
> > 
> > Regularly bootstrapped and tested on x86_64-unknown-linux-gnu,
> > the gcac one is still running (as expected ...).
> > 
> > Any objections?
> Yes actually. I explicitly split these into two so that we get a
> meaningful IRA debugging dump. Please undo this change.

Any particular suggestions?  The easiest "split" is to emit
a '================ reload/lra =============' marker (or similar).
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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]