PCH merge breakage on PA

law@redhat.com law@redhat.com
Wed Jun 5 22:30:00 GMT 2002

 In message <20020605.214459.90825413.davem@redhat.com>, "David S. Miller" 
 >    From: Daniel Berlin <dberlin@dberlin.org>
 >    Date: Wed, 5 Jun 2002 23:46:05 -0400 (EDT)
 >    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.
 > Well, if it is, and we can fix GC to allocate the whole INSN
 > (including the RTL of it's PATTERN) inside of a single contiguous
 > block of memory, it should be cheaper to access this inside of
 > the INSN itself.
True, but the nature of RTL and the way we modify it will probably 
kill any locality you might have.  Think about what the optimizers do
to existing RTL structures :(

There may be cases where we can modify the existing RTL in-place, but
that seems rather dangerous in general.

If we're going to move things out of RTL, then we need to think very carefully
about how to keep moving to a functional interface for the compiler.  While
it's not feasible to have all state in RTL, we don't want to have state
carried around in hundreds of global variables.  ie, I'd like some pointer
do a datastructure which can can pass to a self-contained optimizer (ie,
it doesn't muck around with global variables to get at key items).

What we're really talking about here is basic data structure design and
implementation and a functional interface to the various passes of the
compiler -- we're really suffering from a number of poor design decisions
in a lot of ways.

As to the issue at hand, while Daniel's data is interesting, it doesn't tell
us anything about the temporal locality of access to fields within an
insn.  ie, we may access the LOG_LINKs stuff a lot, but the accesses are
primarily limited to life analysis, combine and the scheduler.  Other passes
which use/modify them are merely trying to keep them up-to-date :-)  Yet
we've allocated a field in every insn for this information.

Another area ripe for fixing is code which doesn't use the datastructures we
do have.  My favorite is CSE which does analysis of insns to effectively
build EBBs -- this is highly inefficient given that we have a CFG and building
the EBBs from a CFG is an order of magnitude simpler than building the EBBs
from an INSN stream.

Anyway, we've got a ton of work to do in this area and it's going to take
time. I just want to make sure that the work we do fits into a model where
passes are more isolated and data live across the passes is not accessed
within passes via global variables.


More information about the Gcc-patches mailing list