From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29872 invoked by alias); 25 Sep 2009 15:16:37 -0000 Received: (qmail 29858 invoked by uid 22791); 25 Sep 2009 15:16:36 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtagate7.de.ibm.com (HELO mtagate7.de.ibm.com) (195.212.17.167) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Sep 2009 15:16:31 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.1/8.13.1) with ESMTP id n8PFGThC013858 for ; Fri, 25 Sep 2009 15:16:29 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 n8PFGQKr3432496 for ; Fri, 25 Sep 2009 17:16:28 +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 n8PFGQEQ014636 for ; Fri, 25 Sep 2009 17:16:26 +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 n8PFGPYn014618; Fri, 25 Sep 2009 17:16:25 +0200 Message-Id: <200909251516.n8PFGPYn014618@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 25 Sep 2009 17:16:25 +0200 Subject: Re: i370 port To: mutazilah@gmail.com (Paul Edwards) Date: Fri, 25 Sep 2009 15:20:00 -0000 From: "Ulrich Weigand" Cc: gcc@gcc.gnu.org In-Reply-To: <0C24A544AA784F4BAFF30DE39853866C@Paullaptop> from "Paul Edwards" at Sep 25, 2009 05:20:27 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/msg00535.txt.bz2 Paul Edwards wrote: > As such, it's appropriate to simply comment it out (which was my > "workaround"). However, before I do so, do you think this is close > to being correct? I already made one correction, to put in that > XL1 rather than doing a fullword (which was always zero obviously). > > > (define_insn "movstrictqi" > [(set (strict_low_part (match_operand:QI 0 "nonimmediate_operand" "+d")) > (match_operand:QI 1 "general_operand" "g"))] > "" > "* > { > check_label_emit (); > if (REG_P (operands[1])) > { > mvs_check_page (0, 8, 0); > return \"STC^I%1,\" CONVLO \"(,13)\;IC^I%0,\" CONVLO \"(,13)\"; > } > mvs_check_page (0, 4, 0); > return \"IC^I%0,=XL1'%X1'\"; > }" > [(set_attr "length" "8")] > ) The one obvious problem I see with this pattern is that the predicate and constraint for operand 1 allow register, immediate and *memory* operands, but the body seems to only handle register and immediate operands correctly. The STC followed by IC is of course correct, but will cause significant penalities on all modern machines. Just about any other way to load the low byte (e.g. and with mask, then or) would be more efficient ... > Which I can clearly see is different. Specifically, the IC by itself is > fine, > although I would have preferred to see the LA instruction there, but for > some reason it is dropping the CLR. That makes it technically > incorrect. This is odd. I don't quite see why this would happen. You should look into the RTL dump files generated via -da to see where the compare insn disappears ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com