From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125571 invoked by alias); 22 Nov 2017 13:03:13 -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 125550 invoked by uid 89); 22 Nov 2017 13:03:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-wm0-f52.google.com Received: from mail-wm0-f52.google.com (HELO mail-wm0-f52.google.com) (74.125.82.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Nov 2017 13:03:10 +0000 Received: by mail-wm0-f52.google.com with SMTP id r68so10260865wmr.3 for ; Wed, 22 Nov 2017 05:03:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=UhNs4SmLcImm2y3SW2goGRM+zhL8g7G/hgnhrdNwOCU=; b=lnzIq3kWOdsdOddxTmeFMuQ/HD9gJ7x/c1ktxGBLgPX/xGImmVzujYcQiQyOfEf2b1 vhSX6mihZwN1X/kxoZ0U40x7rxNkQUuPZSMr+lgnW9AWpslo5BJHCRlvy7ALp+sBTxeJ YZO5/tyiu063AEbHedIn8n9GFXvPfFlOztKDyWYzRIEJKg3eM6uSNGJzxV6q2g+WNdXz 8NUjsqkZe48rhYcr0+a8zn0KVu2K0SD/Rm5oMRC6dQ80v9QsNVDdmGatLjqkU4WMVtZD GoV6jz4vlL+55Y8siqcgjuND2nbVT367nJ6RSLOmmxQjdB6RUqt3H5yCOhZOkikxlq42 iEGQ== X-Gm-Message-State: AJaThX66p0yIMoRzcfPVPQObNh5XIRvn/Yrtw8olrfzNVjHmZ+WrZIlH SE86qoRWGTadrVdjOd0/+YiABMYbKL0= X-Google-Smtp-Source: AGs4zMaGtgf1d2b7+WQ5A6IAAdUffG/VyzJggYba6uOVCV8qOp0hgS8MIRmWEEyGtHI0LY5YBU8d4w== X-Received: by 10.28.138.75 with SMTP id m72mr3921386wmd.97.1511355788544; Wed, 22 Nov 2017 05:03:08 -0800 (PST) Received: from localhost ([2.25.234.120]) by smtp.gmail.com with ESMTPSA id g99sm26415202wrd.72.2017.11.22.05.03.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 22 Nov 2017 05:03:07 -0800 (PST) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,Jakub Jelinek , gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix mult expansion ICE (PR middle-end/82875) References: <20171122091718.GH14653@tucnak> <20171122095523.GK14653@tucnak> Date: Wed, 22 Nov 2017 13:34:00 -0000 In-Reply-To: (Richard Biener's message of "Wed, 22 Nov 2017 11:09:54 +0100 (CET)") Message-ID: <878teyqxdh.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-11/txt/msg02026.txt.bz2 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. Thanks, Richard > Anyway, this doesn't have to happen in stage3, just as a general > note on how I believe we changed things in other places. Richard S. > may remember more here. > > Richard.