From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5984 invoked by alias); 5 Aug 2012 07:47:50 -0000 Received: (qmail 5963 invoked by uid 22791); 5 Aug 2012 07:47:48 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com) (209.85.212.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 05 Aug 2012 07:47:35 +0000 Received: by wibhm2 with SMTP id hm2so748970wib.2 for ; Sun, 05 Aug 2012 00:47:33 -0700 (PDT) Received: by 10.180.100.200 with SMTP id fa8mr9371566wib.19.1344152853500; Sun, 05 Aug 2012 00:47:33 -0700 (PDT) Received: from localhost ([2.26.188.227]) by mx.google.com with ESMTPS id fu8sm7944186wib.5.2012.08.05.00.47.31 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Aug 2012 00:47:32 -0700 (PDT) From: Richard Sandiford To: "H.J. Lu" Mail-Followup-To: "H.J. Lu" ,gcc-patches@gcc.gnu.org, Uros Bizjak , rdsandiford@googlemail.com Cc: gcc-patches@gcc.gnu.org, Uros Bizjak Subject: Re: PATCH: PR rtl-optimization/54157: [x32] -maddress-mode=long failures References: <20120801184138.GA3787@intel.com> <87a9ye1lsh.fsf@talisman.home> Date: Sun, 05 Aug 2012 07:47:00 -0000 In-Reply-To: (H. J. Lu's message of "Thu, 2 Aug 2012 11:20:42 -0700") Message-ID: <87r4rlkcf1.fsf@talisman.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-08/txt/msg00257.txt.bz2 For the record, I can't approve this, but... "H.J. Lu" writes: > i386,md has > > (define_expand "extzv" > [(set (match_operand:SI 0 "register_operand") > (zero_extract:SI (match_operand 1 "ext_register_operand") > (match_operand:SI 2 "const8_operand") > (match_operand:SI 3 "const8_operand")))] > "" > > and mode_for_extraction picks word_mode for operand 1 since > its mode is VOIDmode. This patch changes mode_for_extraction > to return the mode of operand 1 if the pattern accepts any mode. > I added *jcc_btsi_mask_2 since combine now tries a different > pattern, which leads to test failures on gcc.target/i386/bt-mask-1.c > and gcc.target/i386/bt-mask-2. I didn't update *jcc_btsi_mask_1 > instead since I am not sure if it is used elsewhere. Tested on > Linux/x86-64 and Linux/x32. OK for trunk? the mode of the extraction operand is defined to be word_mode for registers (see md.texi), so that at least would need to be updated. But I'm not convinced that the wanted_inner_mode here: if (! in_dest && unsignedp - && mode_for_extraction (EP_extzv, -1) != MAX_MACHINE_MODE) + && mode_for_extraction (EP_extzv, -1, VOIDmode) != MAX_MACHINE_MODE) { - wanted_inner_reg_mode = mode_for_extraction (EP_extzv, 1); - pos_mode = mode_for_extraction (EP_extzv, 3); - extraction_mode = mode_for_extraction (EP_extzv, 0); + wanted_inner_reg_mode = mode_for_extraction (EP_extzv, 1, + inner_mode); + pos_mode = mode_for_extraction (EP_extzv, 3, VOIDmode); + extraction_mode = mode_for_extraction (EP_extzv, 0, VOIDmode); } is right. inner_mode is the mode of the thing we're extracting, which doesn't ncessarily have anything to do with what the ext* patterns support. FWIW, in reply to your force_to_mode message, gen_lowpart_for_combine looks a bit odd: if (omode == imode) return x; /* Return identity if this is a CONST or symbolic reference. */ if (omode == Pmode && (GET_CODE (x) == CONST || GET_CODE (x) == SYMBOL_REF || GET_CODE (x) == LABEL_REF)) return x; So if we know the modes are different, we nevertheless return the original mode for CONST, SYMBOL_REF or LABEL_REF. Surely the caller isn't going to be expecting that? If we're not prepared to change the mode to the one that the caller asked for then I think we should goto fail instead. I don't know if you're hitting that or not. Richard