This is the mail archive of the gcc-patches@gcc.gnu.org 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: Bootstrap failures


Hi,
looks like your patch further increase memory consumption.  Overall
footprint of -O1 insn-attrtab compilation is now 15% up compared to day
before yesterday.

This is due to having more vops at store and load sites (basically one more per load and store and call). This is because all insn-attrtab does is access global memory, and call getter funcs so basically every load and store and call is a touch of the nonlocal vop.

Sadly, *this* vop is  hard to avoid, because we were getting incorrect
results before.  The type-specific patch usually avoided them by TBAA,
but we aren't doing that anymore.  This is just a case where we have
to use an extra vop to be correct in all cases, even though it doesn't
matter in 99% of cases right now.

The only obvious way around this would be to do something similar to
the SMT_USED_ALONE stuff for NONLOCAL, and i really do *not* want to
reimplement that hack for 4.2.

Even though it saved 10% of memory, it ended up being a serious can of worms.

I'll look into this and see if there is any other way to get some low
hanging fruit, but i'm not too hopeful.

You could also turn off all struct aliasing and pruning to fix two of
the PR's, but that doesn't really fix them so much as hide them better
(we'll never be able to eliminate the false aliases that cause the
problem).  Fixing 28778 another way  would requiring keeping a copy of
the alias lists before they are tbaa pruned, so is also just as peak
memory expensive, but not as gc memory intensive  (because you can
obstack these and blow them away if you keep them as bitmaps).

Otherwise, better ideas and patches welcome!


PS Also note that on a checking enabled compiler, insn-attrtab.i takes scheduling 2 : 185.76 (63%) usr 1.11 ( 3%) sys 194.83 (55%) wall 1436 kB ( 1%) ggc

on my machine.
What is up with that (this is before my patch)?


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