PCH merge breakage on PA
Wed Jun 5 20:46:00 GMT 2002
> enclosed PATTERN used to fit in 1 or 2 cache lines, now an INSN tends
> to live on several _PAGES_, yes, _PAGES_. All of this is because we
> allocate different sized things out of different pages. That sucks
> for locality.
> If anything we need to move to a GC that allocates multiple kinds of
> objects out of the same page, and that is something I am working on.
> Anytime people make RTL bigger, I'm going to scream and complain about
> it. I'm going to do this in hopes that people who want to do it
> consider very strongly whether they really need to do so or not. The
> whole compiler has to walk RTL, and this means it is added cost for
> the whole compiler to walk over whatever you've added to some RTL
> object. The cost of adding new things to RTL is on the order of how
> much the compiler looks at RTL.
Hence the reason i provided statistics on how much the compiler uses the
various rtl fields in a followup.
It might actually be a win to move next_insn and prev_insn out of the
INSN, and into an array in the basic block depending on how often we do
insertion in the middle of bb's.
>From a theoretical standpoint, next_insn is, by far, the most accessed
field that could be moved external to the insn (pattern can't be moved).
And it's almost always accessed in a loop, walking insns in a bb.
prev_insn is used much less, but in the same fashion.
pointer dereference -> simple increment (multiple the savings millions of
times) vs the added memmoves (assuming a simple, non-gapped array) from
insertion in the middles.
I'll get some stats and if it look like a good idea, i'll work up a patch
and do some timings.
More information about the Gcc-patches