Re: Optimizer questions/issues with EBCDIC i370/s390 modes.

["Ulrich Weigand" <Ulrich.Weigand@de.ibm.com>]

Dave Pitts wrote:

>The error seems to point at the sdiv_qrnnd macro:

However, that macro looks perfectly OK to me, and in fact it works
on s390.

>../../gcc-3.2/gcc/libgcc2.c: In function `__udiv_w_sdiv':
>../../gcc-3.2/gcc/libgcc2.c:403: `asm' operand requires impossible reload
>../../gcc-3.2/gcc/libgcc2.c:427: `asm' operand requires impossible reload

I've checked this with a cross-compiler to i370-ibm-openedition,
and get the same error.  This appears to be caused by a problem
in the i370 backend.

What happens is that the compiler generates a DImode reload insn of the
form
  (set (reg:DI 0) (reg:DI 49))
for a pseudo 49, which gets assigned a stack slot.

This insn is then rejected by the backend as invalid, which is a bug
in the backend, as any move insn must be valid.

The problem is that the reg:DI 49 operand matches a r_or_s_operand
predicate (because it's a REG), therefore the insn matches this pattern:

  [(set (match_operand:DI 0 "r_or_s_operand" "=dS,m")
        (match_operand:DI 1 "r_or_s_operand" "diS*fF,d*fF"))]

However, as the pseudo was allocated a stack slot, it matches neither
the diS*fF nor the d*fF constraint in strict mode and is thus rejected.
This needs to be fixed; for a move pattern, the constraints need to accept
anything allowed by the predicate (and the predicate really should be
general_operand anyway).  (For other patterns, this requirement is not
quite that strict as reload can fix things up, but for moves, reload
relies on the backend to accept basically anything.)


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com