From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35991 invoked by alias); 8 Jan 2019 14:15:23 -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 14541 invoked by uid 89); 8 Jan 2019 14:15:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=44PM, 44pm, Hx-languages-length:1587, satisfy 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; Tue, 08 Jan 2019 14:15:02 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7CF9BE3DFE; Tue, 8 Jan 2019 14:15:01 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-18.ams2.redhat.com [10.36.116.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1F92D1057068; Tue, 8 Jan 2019 14:15:00 +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 x08EEwkk022130; Tue, 8 Jan 2019 15:14:58 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x08EEtDT022129; Tue, 8 Jan 2019 15:14:55 +0100 Date: Tue, 08 Jan 2019 14:15:00 -0000 From: Jakub Jelinek To: Martin =?utf-8?B?TGnFoWth?= Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Use proper type in linear transformation in tree-switch-conversion (PR tree-optimization/88753). Message-ID: <20190108141455.GG30353@tucnak> Reply-To: Jakub Jelinek References: <1b7be4a1-525c-101d-d897-76b637fd14b1@suse.cz> <20190108125235.GA30353@tucnak> <20190108130835.GB30353@tucnak> <34b59f0a-0a7a-12ad-f2d1-c17d4b949b22@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <34b59f0a-0a7a-12ad-f2d1-c17d4b949b22@suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00407.txt.bz2 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? Jakub