From patchwork Fri Nov 16 08:49:50 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 998795 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-490225-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="Qw09LPYY"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 42xBkk5kB6z9s8F for ; Fri, 16 Nov 2018 19:50:05 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=sU0bs6hsxCn3+wdK4 KjpRkO4DoWTCPRseFTZy17p3p/Km605FoXlsqJ93pf4TIKkCNzuIEa5VTr6Tnv3j QtWMjRjk2bA2cf6SmErgBC0h1CFcoXUiQr5qLt6lZgSCrI/meEcpDLynyDAxAQUm sKdeeWxeeRpMhqNdDj3ykFheho= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; s=default; bh=DTjdJwAz443Hl/iCpdBHhhc RN3c=; b=Qw09LPYYmi5XBpDizWTMhtgwcmfmwgvMcZRdiAJrXVNw+nYlabYCdUk Dgzg9tRtS+dYJxOng6mg2tgpbTZZmkCVYYzVv2Xhcb125SFMI5E4scHlELwu9P7+ w2ij/pfhw0F/A0J4XqE2NV8tjIWHINiO4QmWQvag5TTv1JhKCVTo= 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-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@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 09:49:50 +0100 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-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes 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. Jakub --- 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);