From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110720 invoked by alias); 3 Jul 2019 22:38:31 -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 110711 invoked by uid 89); 3 Jul 2019 22:38:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=Hell 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, 03 Jul 2019 22:38:29 +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 ECEFEC057E65; Wed, 3 Jul 2019 22:38:27 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-37.rdu2.redhat.com [10.10.112.37]) by smtp.corp.redhat.com (Postfix) with ESMTP id 62AFD18BBC; Wed, 3 Jul 2019 22:38:25 +0000 (UTC) Subject: Re: [range-ops] patch 01/04: types for VR_UNDEFINED and VR_VARYING To: Aldy Hernandez , Richard Biener Cc: gcc-patches , Andrew MacLeod References: <481033aa-6ecc-3bcb-c874-becee14c5605@redhat.com> <348c202b-c682-b93b-872b-262d22ffc1be@redhat.com> <982168fa-fc1e-4432-9e15-6ed2cf06195a@redhat.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <696e819a-57a3-5365-6834-f9be8aefbe15@redhat.com> Date: Wed, 03 Jul 2019 22:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <982168fa-fc1e-4432-9e15-6ed2cf06195a@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00311.txt.bz2 On 7/3/19 3:46 AM, Aldy Hernandez wrote: > > > On 7/2/19 4:17 PM, Jeff Law wrote: >> On 7/1/19 2:52 AM, Aldy Hernandez wrote: >>> As discussed before, this enforces types on undefined and varying, which >>> makes everything more regular, and removes some special casing >>> throughout range handling. >>> >>> The min/max fields will contain TYPE_MIN_VALUE and TYPE_MAX_VALUE, which >>> will make it easy to get at the bounds of a range later on.  Since >>> pointers don't have TYPE_MIN/MAX_VALUE, we are using build_zero_cst() >>> and wide_int_to_tree(wi::max_value(precision)), for consistency. >>> UNDEFINED is set similarly, though nobody should ever ask for anything >>> except type() from it.  That is, no one should be asking for the bounds. >>> >>> There is one wrinkle, ipa-cp creates VR_VARYING ranges of floats, >>> presumably to pass around state??  This causes value_range_base::type() >>> and others to fail, even though I haven't actually seen a case of >>> someone actually trying to set a VR_RANGE of a float.  For now, I've >>> built a NOP_EXPR wrapper so type() works correctly.  The correct >>> approach would probably be to avoid creating these varying/undefined >>> ranges in ipa-cp, but I don't have enough ipa-cp-foo to do so. >>> Suggestions welcome, if you don't like special casing this for ipa-cp. >>> Or perhaps as a follow up. >> No idea why we create ranges of floats from ipa-cp.  I presume it's >> coming from propagate_vr_across_jump_function?  Or somewhere else? > > I believe it was ipcp_vr_lattice::set_to_bottom, while changing an > UNDEFINED to VARYING.  IMO, we shouldn't even have created UNDEFINED > ranges of floats.  It's not like we can do anything with float ranges. Note that propagate_vr_across_jump_function calls set_to_bottom ;-) I zero'd in on that one because it did so when presented with something that wasn't an INTEGRAL_TYPE_P and wasn't POINTER_TYPE_P. I think digging into where these are coming from would be advisable. Hell, if you've got types, abort the first time we try to create a range for something that isn't an integer/pointer, then walk backwards. I wouldn't be surprised if we find just a couple sites that are responsible for these problems in ipa-cp. >>> +/* Allocate a new range from the obstack and set it to VARYING for >>> TYPE.  */ >>> +inline value_range * >>> +type_range_cache::new_varying (tree type) >>> +{ >>> +  /* Allocate memory.  */ >>> +  void *p = XOBNEW (&m_range_obj, value_range); >>> +  /* Invoke the constructors on the memory using placement new.  */ >>> +  value_range *new_p = new (p) value_range (); >>> +  /* Initialize it to varying.  */ >>> +  new_p->set_varying (type); >>> +  return new_p; >>> +} >> So is placement new C++98/C++03 or C++11? >> >> If the former then we can use it, if the latter we probably can't since >> we haven't stepped forward to C++11. > > Google isn't cooperating here to narrow the specific C++ version, but > I'm seeing some very old references to placement new, from the mid to > the late 1990s. > > FWIW, the above snippet shows no warnings when compiled with -std=c++-98 > -Wall. Given it compiles in C++-98 mode, let's consider it a non-issue. jeff