This is the mail archive of the
mailing list for the GCC project.
Re: WPA stream_out form & memory consumption
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Martin Liška <mliska at suse dot cz>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 15 Apr 2014 08:00:16 +0200
- Subject: Re: WPA stream_out form & memory consumption
- Authentication-results: sourceware.org; auth=none
- References: <5333E6B8 dot 3000504 at suse dot cz> <5333F3D3 dot 1010009 at suse dot cz> <533C1B04 dot 40407 at suse dot cz> <20140402224344 dot GB1359 at atrey dot karlin dot mff dot cuni dot cz> <533D6FF7 dot 1030009 at suse dot cz> <20140403204013 dot GA16291 at kam dot mff dot cuni dot cz> <53428B1F dot 5050107 at suse dot cz> <CAFiYyc3v-0duCwv8e0twUHhDD56M1PtsQo5bJLaZmCzmVO0LBQ at mail dot gmail dot com> <20140407182034 dot GC26616 at kam dot mff dot cuni dot cz> <CAFiYyc1mccMUrntF0izYdho32qA858B6tCpwViRzRq7Q+Y2OnA at mail dot gmail dot com>
> On Mon, Apr 7, 2014 at 8:20 PM, Jan Hubicka <email@example.com> wrote:
> >> AFAIK we settled on a simpler one dropping columns at stream-out time
> >> that also helped.
> >> As for the correct way to do the optimization we agreed(?) that streaming
> >> the locations elsewhere and using references to them is more appropriate.
> >> At stream-in (or before stream-out) we can then read the location pairs
> >> and sort them before assigning linemap entries.
> > Yep, however what makes difference is the sharing in between compilation units
> > (so sameheaders gets assigned same locations) rather than sharing within the unit
> > (by my experiments). The separate streaming+sorting will only help sharing
> > within the unit.
> > Perhaps something rather simplelike keeping previous stream and merging them will
> > work, too, not sure if better than the simple cache hash though.
> > Or perhaps we can somehow track per-source-file location spaces. Don't know.
> But then linemap itself should provide the ability to lookup existing
> entries rather than you adding another table ontop of it ...
I think the linemap representation does well for frontend use, that produces
locations more or less in sequential manner. It is just LTO that is special.
> Note that you mess up the include stack when you re-use linemap entries
> across files (we at least care to setup the source TU information so you
> get 'included from foo.c' correctly - if you re-use linemaps you get that
> screwed up and ultimately end up with bogus inline stacks for example).
Hmm, never looked into how we track those to be honest. Indeed something that
would need to be matched when chaching, too.
If I get time, I will probably try to impelemnt the separate section
for locators and we can see where we want to go from there.
> > Honza