i370 port

[Paul Edwards]

>> C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
>> FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I
>> ../include
>>          varasm.c
>> (insn 117 429 118 7 (parallel [
>>             (set (reg:SI 64)
>>                 (compare:SI (mem/s:BLK (plus:SI (reg/f:SI 21
>> virtual-stack-vars)
>>
>>                             (const_int 456 [0x1c8])) [232 value+0 S196 
>> A64])
>>                     (mem:BLK (plus:SI (reg/v/f:SI 61 [ desc ])
>>                             (const_int 8 [0x8])) [0 A8])))
>>             (use (const_int 196 [0xc4]))
>>         ]) -1 (nil)
>>     (nil))
>> varasm.c: In function `force_const_mem':
>> varasm.c:3021: internal compiler error: in 
>> instantiate_virtual_regs_lossage,
>> at function.c:3767
>
> OK, so what goes on here is that GCC attempts to replace the "virtual"
> register 21 (virtual-stack-vars) with some real register, that is
> frame pointer + STARTING_FRAME_OFFSET.  It seems for the i370 port,
> this should resolve to
>  register 13 + STACK_POINTER_OFFSET + current_function_outgoing_args_size
>
> Overall, the middle-end would therefore replace "reg 21 + 456" with
> "reg 13 + X", where X is constant computed from 456 + STACK_POINTER_OFFSET
> + current_function_outgoing_args_size.
>
> It will then re-process the insn pattern constraints to verify that the
> resulting insn is still valid.  At this stage, it appears we're running
> into the above error.  I'm not quite sure why this would be case, this
> will require some further debugging why the insn was not recognized ...

This mystery is finally solved.

The previous workaround I had in place failed when I tried to do an
unoptimized compile of varasm.c.  I found this out when I tried speeding
up the experimental configure/make process.  However, since it was
occurring with unoptimized compiles, I thought it would be easier to
track down, and indeed, I found out that the memcmp was only
failing for values 128 and above. 127 was working fine.  That made me
suspect a signed char vs unsigned char problem.

And it's the "QI" below that was causing the grief ...

*** 699,711 ****
      {
        op2 = gen_rtx_MEM (BLKmode, copy_to_mode_reg (SImode, op2));
      }
!
!   /* one circumstance has been found where this short comparison
!      causes an internal error. Could be related to the fact that
!      both displacements were non-zero, which is unusual. So check
!      for that */
!   if (((iv1 == 0) || (iv2 == 0)) &&
!       GET_CODE (operands[3]) == CONST_INT && INTVAL (operands[3]) < 256)
      {
        emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2,
                gen_rtx_SET (VOIDmode, operands[0],
--- 697,705 ----
      {
        op2 = gen_rtx_MEM (BLKmode, copy_to_mode_reg (SImode, op2));
      }
!
!   if (GET_CODE (operands[3]) == CONST_INT
!       && (unsigned)INTVAL (operands[3]) < 256)
      {
        emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2,
                gen_rtx_SET (VOIDmode, operands[0],
***************
*** 747,753 ****
    [(set (match_operand:SI 0 "register_operand" "=d")
        (compare:SI (match_operand:BLK 1 "s_operand" "m")
                 (match_operand:BLK 2 "s_operand" "m")))
!    (use (match_operand:QI 3 "immediate_operand" "I"))]
    "((unsigned) INTVAL (operands[3]) < 256)"
    "*
  {
--- 741,747 ----
    [(set (match_operand:SI 0 "register_operand" "=d")
        (compare:SI (match_operand:BLK 1 "s_operand" "m")
                 (match_operand:BLK 2 "s_operand" "m")))
!    (use (match_operand:SI 3 "immediate_operand" "I"))]
    "((unsigned) INTVAL (operands[3]) < 256)"
    "*
  {

The QI must be a signed char, and thus rejecting any value greater than 127.
As you can see, I changed it to SI, which, with the constraints and tests
in place, should be fine.

Just to be sure, I did a before and after comparison of the generated
assembler for all of GCC (3.4.6) and it all checked out fine.  :-)

BFN.  Paul.