PCH merge breakage on PA

David S. Miller davem@redhat.com
Wed Jun 5 21:48:00 GMT 2002


   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.
   
You're dereferencing memory no matter how you implement this.
Most code is of the form:

	for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
		if (satisfies_condition (insn))
			do_some_work (insn);

And using a table for NEXT/PREV is going to make the memory
references even more sporadic than they are now.

Franks a lot,
David S. Miller
davem@redhat.com



More information about the Gcc-patches mailing list