From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36266 invoked by alias); 16 Nov 2018 08:49:57 -0000 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 Received: (qmail 36247 invoked by uid 89); 16 Nov 2018 08:49:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=int_mode, INT_MODE, H*i:sk:f1bbbd7, target_piece X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Nov 2018 08:49:55 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 38B7C4E916 for ; Fri, 16 Nov 2018 08:49:54 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-75.ams2.redhat.com [10.36.116.75]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BE5D5608F2; Fri, 16 Nov 2018 08:49:53 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id wAG8npga009539; Fri, 16 Nov 2018 09:49:52 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id wAG8np4V009538; Fri, 16 Nov 2018 09:49:51 +0100 Date: Fri, 16 Nov 2018 08:49:00 -0000 From: Jakub Jelinek To: Jeff Law Cc: gcc-patches Subject: [PATCH] Fix expand_binop (PR middle-end/88032) Message-ID: <20181116084950.GE11625@tucnak> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg01427.txt.bz2 Hi! On Wed, Nov 14, 2018 at 09:35:30AM -0700, Jeff Law wrote: > + * optabs.c (expand_binop): Pass INT_MODE to operand_subword_force > + iff the operand is a constant. This broke gcc.target/i386/pr80173.c testcase. The problem is that while operand_subword handles VOIDmode last argument just fine by using GET_MODE (op), so it is only important to use non-VOIDmode if op has VOIDmode. But, operand_subword_force actually has a different behavior, if mode is VOIDmode (or BLKmode), it acts just as operand_subword followed by assertion that it succeeded, rather than by trying to deal with failed operand_subword by forcing it into a pseudo. In the testcase, op is a hard register, on which operand_subword fails, but if it is forced into pseudo, it succeeds. The following patch arranges it by never passing VOIDmode to operand_subword_force, pass int_mode as previously if opN has VOIDmode, but instead of passing VOIDmode otherwise pass the actual mode of the opN operand. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2018-11-16 Jakub Jelinek PR middle-end/88032 * optabs.c (expand_binop): For op0_mode use GET_MODE (op0), unless it is VOIDmode, in which case use int_mode. Similarly for op1_mode. --- gcc/optabs.c.jj 2018-11-14 17:42:53.044049213 +0100 +++ gcc/optabs.c 2018-11-15 15:45:35.949378049 +0100 @@ -1377,8 +1377,12 @@ expand_binop (machine_mode mode, optab b start_sequence (); /* Do the actual arithmetic. */ - enum machine_mode op0_mode = CONSTANT_P (op0) ? int_mode : VOIDmode; - enum machine_mode op1_mode = CONSTANT_P (op1) ? int_mode : VOIDmode; + enum machine_mode op0_mode = GET_MODE (op0); + enum machine_mode op1_mode = GET_MODE (op1); + if (op0_mode == VOIDmode) + op0_mode = int_mode; + if (op1_mode == VOIDmode) + op1_mode = int_mode; for (i = 0; i < GET_MODE_BITSIZE (int_mode) / BITS_PER_WORD; i++) { rtx target_piece = operand_subword (target, i, 1, int_mode); Jakub