From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65187 invoked by alias); 8 Jan 2019 14:25:24 -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 65098 invoked by uid 89); 8 Jan 2019 14:25:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.2 spammy=satisfy X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Jan 2019 14:25:17 +0000 Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 31318ACBA; Tue, 8 Jan 2019 14:25:12 +0000 (UTC) Subject: Re: [PATCH] Use proper type in linear transformation in tree-switch-conversion (PR tree-optimization/88753). To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org References: <1b7be4a1-525c-101d-d897-76b637fd14b1@suse.cz> <20190108125235.GA30353@tucnak> <20190108130835.GB30353@tucnak> <34b59f0a-0a7a-12ad-f2d1-c17d4b949b22@suse.cz> <20190108141455.GG30353@tucnak> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: Date: Tue, 08 Jan 2019 14:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <20190108141455.GG30353@tucnak> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00408.txt.bz2 On 1/8/19 3:14 PM, Jakub Jelinek wrote: > On Tue, Jan 08, 2019 at 02:56:44PM +0100, Martin Liška wrote: >> --- a/gcc/tree-switch-conversion.c >> +++ b/gcc/tree-switch-conversion.c >> @@ -100,6 +100,7 @@ switch_conversion::collect (gswitch *swtch) >> max_case = gimple_switch_label (swtch, branch_num - 1); >> >> m_range_min = CASE_LOW (min_case); >> + gcc_assert (operand_equal_p (TYPE_SIZE (TREE_TYPE (m_range_min)), TYPE_SIZE (TREE_TYPE (m_index_expr)), 0)); >> if (CASE_HIGH (max_case) != NULL_TREE) >> m_range_max = CASE_HIGH (max_case); >> else >> >> and I haven't triggered the assert. >> >>> >>> With using just the constructor elt type, do you count on the analysis to >>> fail if starting with casting the index to the elt type (or unsigned variant >>> thereof) affects the computation? >> >> So hopefully the situation can't happen. Note that if it happens we should not >> generate wrong-code, but we miss an opportunity. > > The situation can happen very easily, just use > int foo (long long x) { int ret; switch (x) { case 1234567LL: ret = 123; break; ... } } > > What I was wondering if doing the computation in the wider (index) type and then > casting to the narrower (ctor value) type could ever optimize something > that doing it on the narrower type can't. > > Say, if index type is unsigned int and elt0 type is unsigned char, if > (a * i + b) % 256 could be the ctor sequence, but one couldn't find > c, d in [0, 255] that (c * (i % 256) + d) % 256 == (a * i + b) % 256. > But don't c = a % 256 and d = b % 256 satisfy that? Yep, that can be an improvement. I can return to it in next stage1. Martin > > Jakub >