Re: i370 port

["Paul Edwards" <mutazilah@gmail.com>]

> Therefore, the i370_branch_dest routine needs to handle
> those as well.  Probably something along the following lines:
>
>  if (GET_CODE (dest) == IF_THEN_ELSE)
>    {
>      if (GET_CODE (XEXP (dest, 1) == LABEL_REF)
> dest = XEXP (dest, 1);
>      else
> dest = XEXP (dest, 2);
>    }
>
>  gcc_assert (GET_CODE (dest) == LABEL_REF);
>  dest = XEXP (dest, 0);

Hi Ulrich.  Thanks for the reply.  I didn't use gcc_assert because I
didn't see it defined anywhere, but the rest of the fix worked fine.

I have now reached the stage where I can (*) self-compile with
optimization on (**).  It takes 6 hours (***).  :-)

(*) I had to disable the MH (multiply halfword) instruction in order
to get it to go through unfortunately.  See below (+).

(**) Except that c-common is being compiled with it off, because of
a bug in the emulator I think, rather than GCC.

(***) It would be closer to 4 hours if I didn't have to do two passes on
the mainframe.  I can't do that though until I can verify the integrity
of the generated code.  And I can't do that until I can get a fully
optimized compile done, because otherwise the register selection changes
slightly on PC vs mainframe causing slight differences in the one
file being compiled without optimization, that prevents an automatic
compare.


(+) Can you spot anything wrong with this?

Here is the error I get:

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
         cppexp.c
cppexp.c: In function `ZZZ_1148':
cppexp.c:980: error: unable to generate reloads for:
(insn 15 14 19 0 (set (reg:SI 4 4 [32])
        (mult:SI (reg:SI 4 4 [30])
            (const_int -858993459 [0xcccccccd]))) 52 {*i370.md:2585} 
(insn_list
12 (nil))
    (expr_list:REG_DEAD (reg:SI 4 4 [30])
        (nil)))
cppexp.c:980: internal compiler error: in find_reloads, at reload.c:3690
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gccmvs.sourceforge.net> for instructions.


I can bypass this error by commenting out the MH pattern, and
the code that would normally invoke it.  Note that I didn't write
that "XXX trouble" stuff, and I don't know if it is still relevant.

;
; mulsi3 instruction pattern(s).
;

(define_expand "mulsi3"
  [(set (match_operand:SI 0 "general_operand" "")
        (mult:SI (match_operand:SI 1 "general_operand" "")
                 (match_operand:SI 2 "general_operand" "")))]
  ""
  "
{
  /*if (GET_CODE (operands[1]) == CONST_INT
      && REG_P (operands[0])
      && CONST_OK_FOR_LETTER_P (INTVAL (operands[1]), 'K'))
    {
      emit_insn (gen_rtx_SET (VOIDmode, operands[0],
                          gen_rtx_MULT (SImode, operands[2], operands[1])));
    }
  else if (GET_CODE (operands[2]) == CONST_INT
           && REG_P (operands[0])
           && CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K'))
    {
      emit_insn (gen_rtx_SET (VOIDmode, operands[0],
                          gen_rtx_MULT (SImode, operands[1], operands[2])));
    }
  else */
    {
      rtx r = gen_reg_rtx (DImode);

      /* XXX trouble.  Below we generate some rtx's that model what
       * is really supposed to happen with multiply on the 370/390
       * hardware, and that is all well & good.  However, during 
optimization
       * it can happen that the two operands are exchanged (after all,
       * multiplication is commutitive), in which case the doubleword
       * ends up in memory and everything is hosed.  The gen_reg_rtx
       * should have kept it in a reg ...  We hack around this
       * below, in the M/MR isntruction pattern, and constrain it to
       * \"di\" instead of \"g\".  But this still ends up with lots & lots 
of
       * movement between registers & memory and is an awful waste.
       * Dunno how to untwist it elegantly; but it seems to work for now.
       */
      if (GET_CODE (operands[1]) == CONST_INT)
      {
      emit_insn (gen_rtx_SET (VOIDmode,
                          gen_rtx_SUBREG (SImode, r, GET_MODE_SIZE 
(SImode)),
                                          operands[1]));
      emit_insn (gen_rtx_SET (VOIDmode, r,
                          gen_rtx_MULT (DImode, r, operands[2])));
      }
      else
      {
      emit_insn (gen_rtx_SET (VOIDmode,
                          gen_rtx_SUBREG (SImode, r, GET_MODE_SIZE 
(SImode)),
                                          operands[2]));
      emit_insn (gen_rtx_SET (VOIDmode, r,
                          gen_rtx_MULT (DImode, r, operands[1])));
      }
      emit_insn (gen_rtx_SET (VOIDmode, operands[0],
                          gen_rtx_SUBREG (SImode, r, GET_MODE_SIZE 
(SImode))));
    }
  DONE;
}")

;(define_insn ""
;  [(set (match_operand:SI 0 "register_operand" "=d")
;       (mult:SI (match_operand:SI 1 "register_operand" "0")
;                (match_operand:SI 2 "immediate_operand" "K")))]
;  ""
;  "*
;{
;  check_label_emit ();
;  mvs_check_page (0, 4, 0);
;  return \"MH  %0,%H2\";
;}"
;   [(set_attr "length" "4")]
;)

; See mulsi3 comment above as to why this is constrained to
; "di" rather than "g"
(define_insn ""
  [(set (match_operand:DI 0 "register_operand" "=d")
        (mult:DI (match_operand:DI 1 "general_operand" "0")
                 (match_operand:SI 2 "general_operand" "di")))]
  ""
  "*
{
  check_label_emit ();
  if (REG_P (operands[2]))
    {
      mvs_check_page (0, 2, 0);
      return \"MR       %0,%2\";
    }
  mvs_check_page (0, 4, 0);
  return \"M    %0,%2\";
}"
   [(set_attr "length" "4")]
)


Regardless, when that code is NOT commented out, such that I get that
error, it is surprising that it is passing through this code:

      emit_insn (gen_rtx_SET (VOIDmode, r,
                          gen_rtx_MULT (DImode, r, operands[2])));

where it is clearly attempting to do a DImode multiply, and thus
shouldn't be matching the MH, that I am getting the problem.

Although almost all of the GCC code can be compiled with
this in place.  It's only when I have that very large constant,
0xcccccccd, not sure where that's coming from, that I have
the problem.

Commenting out the MH pattern (and the code that tries to
call MH) makes it happily use the proper intended MR instruction,
and everything works so well that gcc 3.4.6 can self-compile
on an EBCDIC environment.  :-)

Any ideas?

Thanks.  Paul.