From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90120 invoked by alias); 25 Aug 2017 04:56:18 -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 90106 invoked by uid 89); 25 Aug 2017 04:56:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=integral 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, 25 Aug 2017 04:56:16 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A26E380462; Fri, 25 Aug 2017 04:56:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A26E380462 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law@redhat.com Received: from localhost.localdomain (ovpn-116-59.phx2.redhat.com [10.3.116.59]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6A2717900F; Fri, 25 Aug 2017 04:56:14 +0000 (UTC) Subject: Re: [66/77] Use scalar_mode for constant integers To: gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org References: <8760ewohsv.fsf@linaro.org> <878tjsd81e.fsf@linaro.org> From: Jeff Law Message-ID: <21fd25b3-e035-8754-4c02-b094a933c0c0@redhat.com> Date: Fri, 25 Aug 2017 05:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <878tjsd81e.fsf@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg01487.txt.bz2 On 07/13/2017 03:02 AM, Richard Sandiford wrote: > This patch treats the mode associated with an integer constant as a > scalar_mode. We can't use the more natural-sounding scalar_int_mode > because we also use (const_int 0) for bounds-checking modes. (It might > be worth adding a bounds-specific code instead, but that's for another > day.) Is that the only reason why we can't use scalar_int_mode here -- the bounds checking stuff? What if it were to just magically disappear? > > This exposes a latent bug in simplify_immed_subreg, which for > vectors of CONST_WIDE_INTs would pass the vector mode rather than > the element mode to rtx_mode_t. > > I think the: > > /* We can get a 0 for an error mark. */ > || GET_MODE_CLASS (mode) == MODE_VECTOR_INT > || GET_MODE_CLASS (mode) == MODE_VECTOR_FLOAT An interesting nugget. It appears Aldy's commit message, but not in the approved patch from June 2002. > > in immed_double_const is dead. trunc_int_mode (via gen_int_mode) > would go on to ICE if the mode fitted in a HWI, and surely plenty > of other code would be confused to see a const_int be interpreted > as a vector. We should instead be using CONST0_RTX (mode) if we > need a safe constant for a particular mode. Yea, if we wanted to use 0 as an error mark, we should be using it via CONST0_RTX (mode). > > We didn't try to make these functions take scalar_mode arguments > because in many cases that would be too invasive at this stage. > Maybe it would become feasible in future. Also, the long-term > direction should probably be to add modes to constant integers > rather than have then as VOIDmode odd-ones-out. That would remove > the need for rtx_mode_t and thus remove the question whether they > should use scalar_int_mode, scalar_mode or machine_mode. THe lack of a mode on CONST_INTs is a long standing wart. It's been eons since we really thought about how to fix it. I'd have to dig real deep to remember why we've let the wart stand so long > > The patch also uses scalar_mode for the CONST_DOUBLE handling > in loc_descriptor. In that case the mode can legitimately be > either floating-point or integral. > > 2017-07-13 Richard Sandiford > Alan Hayward > David Sherwood > > gcc/ > * emit-rtl.c (immed_double_const): Use is_a instead > of separate mode class checks. Do not allow vector modes here. > (immed_wide_int_const): Use as_a . > * explow.c (trunc_int_for_mode): Likewise. > * rtl.h (wi::int_traits::get_precision): Likewise. > (wi::shwi): Likewise. > (wi::min_value): Likewise. > (wi::max_value): Likewise. > * dwarf2out.c (loc_descriptor): Likewise. > * simplify-rtx.c (simplify_immed_subreg): Fix rtx_mode_t argument > for CONST_WIDE_INT. OK. jeff