From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by sourceware.org (Postfix) with ESMTPS id 1FEEC3860742 for ; Mon, 21 Nov 2022 16:49:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1FEEC3860742 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x1035.google.com with SMTP id k5so10917254pjo.5 for ; Mon, 21 Nov 2022 08:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=WSxaLyYiiRJSGsxGtkiEU6TgY6jn79rDzPhj143P3bQ=; b=hmMCMS5ehm0l/EqxOtNK9L99FuoIzQA6dXiV68gsmEpD+mWVALk9oDAWEI1FEjK8xn YFJNbOzRJgtqMr1yEFZ7zvXwtYCX9n+kJlxDWGC5cJ54jLE/22OmLfC/N0ofKD0+WApM paCNH6qmEEOOy66XD1LeOpUnOB4E5nraZN4tBm56+xLApl99RdUY/cAP+yoPRXaaR3hz gCpDM2TdPA9Ri6yfJLkdbFTsZVSOWuqlKjcmlGfIOvLdCjWCEy+zGgvBxVwEA9R2S8aP RNBA4sGnIwpKIdarhMyIHrcpz3MmH8u2NGHWoPPY801NXbw9b/PADxxmHa+dj7PYahqg Qg3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WSxaLyYiiRJSGsxGtkiEU6TgY6jn79rDzPhj143P3bQ=; b=EJVd5uOZBaRVVItbPhOcuPXCcHL8PH9Kv4jLHUvKedx9zCLHwfRgGr3nwPF9bI4utg DM0hhwCee4WDmdOhUrQTuqxTzhVMlA74eZsUcTGSUkwxooMD3lz64mh1N4Ik3c2NtiNF MC22pUV9hXZPVq5n9eouN9gh9gXOq50/5dbYX7wKDqTTu781c+IAc/lvZH7lTJ5rUKn6 yAe5epdl9PFQu8clSVUngEZGchKgznMOTZ7OwkgbYQAlLWvy/ot99Xbw+SUibJxOnL0+ //Ud3GCnOhK4z6JbvZS6oZGIK2aHOvVZAD6cGixGLxCmY1TtvQGMvD5jchZTPvJsOaDZ Nm8g== X-Gm-Message-State: ANoB5pmauIVaEzfjWQKMTT/LSlCb9U1dG2D3nY1UG6tyBqdT4vu2JiT7 aIRV9j3WbPdI83x75s4cAuY= X-Google-Smtp-Source: AA0mqf73fYybHvLSdqX5bI9PyjKB/CnBZ3N8pRK9JA0vw8EcK3XIsR1kp0rrlXMJBRTM6gAB/UaPhA== X-Received: by 2002:a17:902:db0c:b0:189:1963:d0d7 with SMTP id m12-20020a170902db0c00b001891963d0d7mr134218plx.100.1669049386883; Mon, 21 Nov 2022 08:49:46 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id g10-20020aa796aa000000b00571f4386697sm8952649pfk.24.2022.11.21.08.49.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Nov 2022 08:49:45 -0800 (PST) Message-ID: <2eb36356-ffbf-6c8b-2824-08e204280d52@gmail.com> Date: Mon, 21 Nov 2022 09:49:44 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH] Remove legacy VRP (maybe?) Content-Language: en-US To: Aldy Hernandez , Jakub Jelinek , Richard Biener , "MacLeod, Andrew" , gcc-patches References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 11/21/22 09:35, Aldy Hernandez via Gcc-patches wrote: > I've been playing around with removing the legacy VRP code for the > next release. It's a layered onion to get this right, but the first > bit is pretty straightforward and may be useful for this release. > Basically, it entails removing the old VRP pass itself, along with > value_range_equiv which have no producers left. The current users of > value_range_equiv don't put anything in the equivalence bitmaps, so > they're basically behaving like plain value_range. > > I removed as much as possible without having to change any behavior, > and this is what I came up with. Is this something that would be > useful for this release? Would it help release managers have less > unused cruft in the tree? > > Neither Andrew nor I have any strong feelings here. We don't foresee > the legacy code changing at all in the offseason, so we can just > accumulate these patches in local trees. I'd lean towards removal after gcc-13 releases. jeff