Illegitimate address in REG_EQUAL note: legal?

[Ulrich Weigand <weigand at immd1 dot informatik dot uni-erlangen dot de>]

Hello,

another problem with the current 3.1 on s390: 

gcse constant-propagation can substitute a constant
term for a register into a memory address, with the
resulting address being illegitimate.  

(Specifically, gcse has pulled a (const (unspec ...))
construct used to specify a GOT offset larger than 4K
out of the constant pool and placed it inline into
the address.  This does not work.)

Now, try_replace_reg does notice that something 
isn't OK, as validate_replace_src fails.  However,
if that happens, the illegitimate address is still
placed into a REG_EQUAL note which is attached to
the insn.

Unfortunately, this note gets promoted to a REG_EQUIV
note later on, and when reload sees this note, it will
create a reg_equiv_address entry for the pseudo.
However, while req_equiv_address addresses are presumed
to be illegitimate, reload does assume they are so for
a couple of special reasons (i.e. not strictly legitimate,
CONST_INT offset out of range etc.)

In this particular case, the address doesn't fit into
any of these categories, and so find_reloads_address
doesn't handle it correctly.  This results in the
address showing up un-reloaded in the rtx after reload,
causing an ICE in cleanup_subreg_operands due to an
unrecognized insn.


I'm at a loss to decide which of the involved parties
is at fault here.  Either:

- REG_EQUAL notes should never contain illegitimate
  memory addresses.

  In this case gcse try_replace_reg needs to be fixed.
  [ Why does it keep things it *knows* to be invalid
  around anyway?  The comment says it's done so as
  'to not lose information'.  Am I missing something
  here? ]

- REG_EQUAL notes may contain illegitimate addresses,
  but REG_EQUIV notes not.

  In this case local-alloc probably needs to add
  checks to ensure it only promotes valid REG_EQUAL
  notes to REG_EQUIV.

- Both REG_EQUIV and REG_EQUAL notes may contain
  illegitimate addresses.

  Then reload need to either handle such addresses
  correctly in find_reloads_address, or else check
  the note in advance and ignore it if is isn't
  legitimate.

Any suggestions?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de