PCH merge breakage on PA

Daniel Berlin dberlin@dberlin.org
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 mailing list