From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6604 invoked by alias); 22 Nov 2017 13:07:21 -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 5532 invoked by uid 89); 22 Nov 2017 13:07:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=easiest, stand 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; Wed, 22 Nov 2017 13:07:15 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E323DC0567A2; Wed, 22 Nov 2017 13:07:13 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-247.ams2.redhat.com [10.36.116.247]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 79B8E17197; Wed, 22 Nov 2017 13:07:13 +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 vAMD7AGE021304; Wed, 22 Nov 2017 14:07:10 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id vAMD77V6021303; Wed, 22 Nov 2017 14:07:07 +0100 Date: Wed, 22 Nov 2017 13:50:00 -0000 From: Jakub Jelinek To: Richard Biener , gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Subject: Re: [PATCH] Fix mult expansion ICE (PR middle-end/82875) Message-ID: <20171122130707.GT14653@tucnak> Reply-To: Jakub Jelinek References: <20171122091718.GH14653@tucnak> <20171122095523.GK14653@tucnak> <878teyqxdh.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878teyqxdh.fsf@linaro.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg02027.txt.bz2 On Wed, Nov 22, 2017 at 01:03:06PM +0000, Richard Sandiford wrote: > Richard Biener writes: > > On Wed, 22 Nov 2017, Jakub Jelinek wrote: > > > >> On Wed, Nov 22, 2017 at 10:41:19AM +0100, Richard Biener wrote: > >> > How much churn would it be to pass down a mode alongside the operands > >> > in expand_binop? Can't find it right now but didn't we introduce > >> > some rtx_with_mode pair-like stuff somewhen? > >> > >> We have rtx_mode_t for that. But there are 240+ calls to expand_binop, > >> and even if we add an overload that will transform it, unless we forcefully > >> inline it wouldn't that slow down all the spots a little bit? > >> The thing is, for the vast majority of binary ops we don't need the operand > >> modes, it is mainly comparisons, second arg of shifts/rotates and this > >> widening case. > > > > Ok, so maybe split expand_binop then to the class of cases where we do > > need the mode and a class where we don't then? > > > > We don't have to use rtx_mode_t we can just pass two arguments. Not > > sure what is more convenient to use. > > FWIW, rtx_mode_t was only really added so that we have a single blob > for wi:: calls (with the hope that it would eventually be replaced > with just the rtx once CONST_INTs have a mode). I think it'd be > more consistent to use separate arguments for other cases. So perhaps it would be easiest to just add one defaulted to VOIDmode argument to expand_binop, say aux_mode, which would stand for whatever other second mode the optab needs (could be operand mode for comparisons or the widening stuff, or op1 mode for shifts, etc.). If it is VOIDmode, it wouldn't be used. Jakub