https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66785

Jim Wilson <wilson at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu.org

--- Comment #2 from Jim Wilson <wilson at gcc dot gnu.org> ---
The operand_rr_info struct has arrays sized by MAX_REGS_PER_ADDRESS.

regrename is calling record_operand_use for a write to an operand.  It is also
calling record_operand_use when a use (read or write) overlaps an earlier
write.  Hence a mem operand using an address with N regs can overlap N previous
writes explaining the use of MAX_REGS_PER_ADDRESS. 

However, we can also have an operand that is N-regs wide that can overlap N
previous 1-reg wide writes.  Thus, we need to be able to handle the number of
regs in the widest possible mode also.  If we can have multiword regs used
inside an address, things get even more complicated, but that isn't an issue at
the moment.

So instead of using just MAX_REGS_PER_ADDRESS, we need here something like
#define OPERAND_RR_INFO_ARRAY_SIZE                                        \
  MAX (MAX_REGS_PER_ADDRESS,                                              \
       (MAX_BITSIZE_MODE_ANY_MODE / BITS_PER_UNIT) / MIN_UNITS_PER_WORD)

Unfortunately, this increases the array size from 2 to 16 for aarch64, as the
widest mode is CXImode which takes 16 registers.  This change may be wasting
too much memory to be useful.  This only affects the ports that have their own
target dependent regrename pass though, which is only c6x and aarch64 at the
moment.

I suspect that we only need an array size of 4 for arm, as the widest
instructions operate on 4 registers at a time, but I don't see an obvious way
to get that info without adding another macro.

I don't see any obvious uses of the chains member in operand_rr_info.  The c6x
and aarch64 ports are only using the heads member.  So we could partially
offset the memory size increase by dropping the chains member.

Or maybe we can modify mode creation to avoid getting the CXI mode, as we don't
need it.  It is created automatically because we define XI as an 8-wide integer
mode.  Without CXImode the widest modes are only 8 registers wide.  Combined
with the removal of the chains member we are only doubling the size of this
structure.

Reply via email to