On Tue, Sep 22, 2020 at 09:02:08AM -0400, Marek Polacek via Gcc-patches wrote:
> On Tue, Sep 22, 2020 at 10:30:00AM +0200, Martin Liška wrote:
> > On 9/22/20 9:47 AM, Christophe Lyon wrote:
> > > On Wed, 2 Sep 2020 at 15:29, Martin Liška <mli...@suse.cz> wrote:
> > > >
> > > > On 9/1/20 4:04 PM, Jan Hubicka wrote:
> > > > > > The patch is about usage of MiB in memory allocation reports.
> > > > > > I see it much better readable than values displayed in KiB:
> > > > > >
> > > > > > Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB
> > > > > > -> 19 MiB} {GC 19 MiB} {heap 12 MiB}
> > > > > > Reading the symbol table:
> > > > > > Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC
> > > > > > 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB}
> > > > > > Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB}
> > > > > > <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB}
> > > > > > {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB}
> > > > > > {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const>
> > > > > > {GC 30 MiB} {heap 15 MiB} {GC 30 MiB}
> > > > > > Merging symbols: {heap 15 MiB}Materializing decls:
> > > > > > <odr> {heap 15 MiB} <whole-program> {heap 15 MiB}
> > > > > > <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap
> > > > > > 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15
> > > > > > MiB} <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const>
> > > > > > {heap 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2
> > > > > > MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB}
> > > > > > <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats>
> > > > > > {heap 15 MiB}
> > > > > > Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB}
> > > > > > ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns)
> > > > > > ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns)
> > > > >
> > > > > One problem I see here is that while it is OK for Firefox builds it is
> > > > > bit too coarse for smaller testcases where the memory use is still
> > > > > importnat. I guess we may just print KBs before the large gets too
> > > > > large, just like norton commander does? :)
> > > >
> > > > Sure, let's do it using SIZE_AMOUNT macro.
> > > >
> > > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > > >
> > >
> > > Hi,
> > >
> > > This change is causing gcc.dg/timevar[12].C to fail randomly, eg:
> > > FAIL: g++.dg/ext/timevar1.C -std=gnu++2a (test for excess errors)
> > > Excess errors:
> > > phase opt and generate : 0.00 ( 0%) 0.00 ( 0%)
> > > 0.01 ( 50%) 8904 ( 0%)
> > > callgraph construction : 0.00 ( 0%) 0.00 ( 0%)
> > > 0.01 ( 50%) 4096 ( 0%)
> > >
> > > because SIZE_AMOUNT generates no suffix if the size is < 10k, and those
> > > tests
> > > now use dg-prune-output "k" and dg-prune-output " 0 "
> > > which is not enough.
> > >
> > > Can you fix this?
> >
> > Sorry for the breakage. I hope Marek has a fix that he'll install.
>
> Should be fixed now!
Ah, timevar1.C has the same problem. Will fix that one now too.
Marek
