From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20771 invoked by alias); 15 Sep 2009 12:59:30 -0000 Received: (qmail 20746 invoked by uid 22791); 15 Sep 2009 12:59:27 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_PASS,WEIRD_PORT X-Spam-Check-By: sourceware.org Received: from mail-px0-f191.google.com (HELO mail-px0-f191.google.com) (209.85.216.191) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Sep 2009 12:59:23 +0000 Received: by pxi29 with SMTP id 29so3402017pxi.3 for ; Tue, 15 Sep 2009 05:59:21 -0700 (PDT) Received: by 10.114.163.26 with SMTP id l26mr13697222wae.173.1253019561538; Tue, 15 Sep 2009 05:59:21 -0700 (PDT) Received: from Paullaptop (203-214-134-90.perm.iinet.net.au [203.214.134.90]) by mx.google.com with ESMTPS id 21sm553164pzk.3.2009.09.15.05.59.16 (version=SSLv3 cipher=RC4-MD5); Tue, 15 Sep 2009 05:59:18 -0700 (PDT) Message-ID: From: "Paul Edwards" To: "Ulrich Weigand" Cc: "Joseph S. Myers" , References: <200909141542.n8EFg86x026189@d12av02.megacenter.de.ibm.com> In-Reply-To: <200909141542.n8EFg86x026189@d12av02.megacenter.de.ibm.com> Subject: Re: i370 port Date: Tue, 15 Sep 2009 12:59:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-09/txt/msg00262.txt.bz2 > 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 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.