Regression due to tree loop opt / expand weirdness

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

Hello,

since several days the memcpy-2.c test case fails on s390x-ibm-linux.
The (reduced) test case is:

char buf[101];
void test (int len)
{
  char *p;
  int i;

  p = buf;
  for (i = 0; i < len; i++, p++)
    f (*p);
}

and its loop gets transformed by the tree-level loop optimizer into:

  # p_1 = PHI <p_12(6), &buf(3)>;
<L0>:;
  p_16 = p_1;
  D.1061_8 = *p_16;
  D.1062_9 = (int) D.1061_8;
  f (D.1062_9);
  p_4 = p_1 + 1B;
  p_12 = p_4;
  D.1092_15 = (unsigned int) p_12;
  D.1093_14 = (unsigned int) &buf;
  D.1094_13 = D.1092_15 - D.1093_14;
  i_5 = (int) D.1094_13;
  if (i_5 < len_7) goto <L9>; else goto <L8>;

The expander then transforms the D.1093 assigment into:

(insn 45 43 47 (set (reg:SI 61 [ D.1093 ])
        (symbol_ref:SI ("buf") <var_decl 0x20000286c40 buf>)) -1 (nil)
    (nil))

which subsequently ICEs as we cannot handle symbol_ref:SI in 64-bit mode.

Now there's a couple of odd things here.  First of all, the transformation
of the loop exit condition is really weird; even on 32-bit where compilation
is successful, this exit condition is so complicated that the RTL optimizers
don't manage to transform the loop into doloop form any more.


The other odd thing is why the expander attempts to generate a symbol_ref
with anything other than Pmode.  This appears to be done by the combination
of expand_expr_addr_expr and convert_memory_address, which can cause any
mode to appear in a symbol_ref that valid_pointer_mode accepts.

Now it is true that valid_pointer_mode accepts SImode on s390x, because
we want to allow the user to declare SImode pointer variables (this is
mainly useful for TPF).  What I expected this to achieve was to generate
conversion code whenever accessing a variable declared thus -- but all
internal use of addresses, in particular all symbolic address arithmetic
would continue to be performed in Pmode.

Richard, I appears you've added the valid_pointer_mode check to 
expand_expr_addr_expr -- could you elaborate how the back-end is
supposed to handle this?  Do we need to perform all the symbolic
address arithmetic (e.g. pic/tls address generation) in non-Pmode
in order to allow for non-Pmode user pointer variables?

Bye,
Ulrich

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