From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16526 invoked by alias); 15 Sep 2009 13:51:10 -0000 Received: (qmail 16517 invoked by uid 22791); 15 Sep 2009 13:51:09 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_42,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.17.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Sep 2009 13:51:02 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id n8FDoxeJ002160 for ; Tue, 15 Sep 2009 13:50:59 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8FDoxZa1274014 for ; Tue, 15 Sep 2009 15:50:59 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8FDox5a009834 for ; Tue, 15 Sep 2009 15:50:59 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n8FDownl009821; Tue, 15 Sep 2009 15:50:58 +0200 Message-Id: <200909151350.n8FDownl009821@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 15 Sep 2009 15:50:58 +0200 Subject: Re: i370 port To: mutazilah@gmail.com (Paul Edwards) Date: Tue, 15 Sep 2009 13:51:00 -0000 From: "Ulrich Weigand" Cc: joseph@codesourcery.com (Joseph S. Myers), gcc@gcc.gnu.org In-Reply-To: from "Paul Edwards" at Sep 15, 2009 10:59:07 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00266.txt.bz2 Paul Edwards wrote: > 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. Ah, I see this macro was only added in 4.x. In 3.x you should just use abort () directly, like so: if (GET_CODE (dest) != LABEL_REF) abort (); > (*) I had to disable the MH (multiply halfword) instruction in order > to get it to go through unfortunately. See below (+). > (+) Can you spot anything wrong with this? > ;(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")] > ;) The combination of predicates and constraints on this insn is broken. Before reload, the predicate "immediate_operand" explicitly allows *any* SImode immediate value. However, during reload, the "K" constraint accepts only a subset of values. As there is no other alternative, and the insn supports neither memory nor register operands, this is impossible for reload to fix up. In addition, I don't quite understand how this pattern works in the first place; MH requires a memory operand, but this pattern seems to output an immediate value as operand. Is there some magic going on in your assembler? If you indeed want to output immediate values here, you should probably define a new *predicate* that constrains the set of allowed values even before reload. In the s390 port, we're instead modelling the MH instruction with a memory operand (this still allows the generic parts of GCC to push immediate operands into memory, if they are in range for an HImode operand): (define_insn "*mulsi3_sign" [(set (match_operand:SI 0 "register_operand" "=d") (mult:SI (sign_extend:SI (match_operand:HI 2 "memory_operand" "R")) (match_operand:SI 1 "register_operand" "0")))] "" "mh\t%0,%2" [(set_attr "op_type" "RX") (set_attr "type" "imul")]) > ; 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")] > ) This also seems broken. A MULT:DI must have two DImode operands, it cannot have one DImode and one SImode operand. Also, it is in fact incorrect that it takes the full DImode first operand; rather, it only uses the low 32-bit of its first operand as input. In the s390 port we're modelling the real behavior of the instruction using two explicit SIGN_EXTEND codes: (define_insn "mulsidi3" [(set (match_operand:DI 0 "register_operand" "=d,d") (mult:DI (sign_extend:DI (match_operand:SI 1 "register_operand" "%0,0")) (sign_extend:DI (match_operand:SI 2 "nonimmediate_operand" "d,R"))))] "!TARGET_64BIT" "@ mr\t%0,%2 m\t%0,%2" [(set_attr "op_type" "RR,RX") (set_attr "type" "imul")]) > 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. Well, the point of optimization is that the RTXes do not stay the way they were originally expanded ... The optimizers will attempt to perform various generic optimization on the code, and if the back-end claims to support a pattern that implements any of those optimized forms, it will get used. In this case, even though you expanded a DImode multiply, common code may notice that it can be optimized to a SImode multiply instead. Generally speaking, your RTX patterns *must* be fully correct and represent the actual behavior of the machine in all cases. If there are corner cases formally allowed by the RTX pattern, but the behavior of the machine differs, this may cause breakage. Even if your expanders avoid those corner cases when using your patterns, this will not be true for the optimizers. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com