Re: rtx_equal_function_value_matters

["David S. Miller" <davem at dm dot cobaltmicro dot com>]

   From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>
   Date: Thu, 19 Nov 1998 19:58:18 +0100 (CET)

[ Some discussion has been going on about recent sparc64
  failures due to one of Bernd's regclass() changes which
  introduces calls there to gen_move expanders which were
  never being called before. ]

   Ok, this helped so that I can now compile kernel with egcs-current
   and boot it. It works mostly, but something is broken in networking
   (e.g. ping does not work very well). I'll be investigating more.

I thought about this problem some more, and I think it is bogus that
local alloc etc. is blowing up.  Local alloc is blowing up because
regclass() is now generating new pseudos and nobody between regclass()
and local alloc resize the reg_info varray.

The real problem is that the varray for REG_N_SETS etc. is not being
resized after these gen_move calls are done in the new regclass()
code, that is the bug.  And it shows up because of Bernd's change.  So
the obvious fix is to allocate_reg_info() has to be called someplace
after that call to regclass() but this is really ugly (see below).

I begin to see that every time someone adds some new place where move
sequences are generated, a new massive failure is present for sparc64.
Sparc64 I guess is the only platform where generating pseudos any time
before reload for many move patterns is so common that the varray's
for register information overflow.  Last time this happened it was in
loop.c

The fact that we keep adding new calls to allocate_reg_info() for each
new case we find before reload runs to resize this table is a sign of
misdesign.  I think we should fix the core problem and keep this table
up to date (size wise) in a cleaner way.

Ideas?

Later,
David S. Miller
davem@dm.cobaltmicro.com