From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 45AF838582A7 for ; Sat, 9 Jul 2022 19:31:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 45AF838582A7 Received: from mail-oa1-f71.google.com (mail-oa1-f71.google.com [209.85.160.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-308-H1QyqdaBO7q8gfBa0WF9Yw-1; Sat, 09 Jul 2022 15:31:53 -0400 X-MC-Unique: H1QyqdaBO7q8gfBa0WF9Yw-1 Received: by mail-oa1-f71.google.com with SMTP id 586e51a60fabf-fdc4b531bfso841209fac.13 for ; Sat, 09 Jul 2022 12:31:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dfu0RLgAugARbGmeLMSASP6c/Od1qiL0nW6GDoyob4Y=; b=FVL/lRd3eLjK98tIYLRr/xaQXoHYsPOJy3fi+cXhk6loy3ezoSsPBaYqC9+dHEqBlV b4ooR7qIIaO3NK7o4YMVNJxvP6r7/xoopQsVTnV1kXyAR4JJwNj5DvojoknyLJVmuo6g Pq/s4ueHpt6iPrNhUrpt3vDtM4LB3Iv8rEfTMe0ljgFbpOfK9JOau9Dwp+HK7mHu1TSL 3XDiiAIoF9zncr3VdIhws0rCENjyydKTZZjzevxR+Wn4I4sIGJzXwUU3Jdj4rIMk2/Tw zwPaj5RupIi3/IHEMoy+i/3VJ/T1ij+HO5Kn7S0JmdveO5UkhXhykUUDI1EjgPIbbNUq u4Jw== X-Gm-Message-State: AJIora+JkvRuXyulDwWvBt+uXJ1pZYAPdKwfaLRxSGfchfaXnLRANaEa xJosBdi9uQNJWtyHD+0twMRX8GoBALi12Kehmr+KgHvvgpwG8nU1ef76CEAFGuhd0D9j46lFr+T AmKBHKaaSDRi6sJFqvCAaJCRDpK6ZkOIlSA== X-Received: by 2002:a05:6830:48:b0:616:ada0:5378 with SMTP id d8-20020a056830004800b00616ada05378mr4399152otp.276.1657395112829; Sat, 09 Jul 2022 12:31:52 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uKQ1EN5LjDykUxN9/jS3dYiLcEdPOqP0iiroWFUiPYe9jkpNDId6dJZZQ9YgnMNbgUViq8lOdti+IaHd2Bq0w= X-Received: by 2002:a05:6830:48:b0:616:ada0:5378 with SMTP id d8-20020a056830004800b00616ada05378mr4399142otp.276.1657395112549; Sat, 09 Jul 2022 12:31:52 -0700 (PDT) MIME-Version: 1.0 References: <20220706171019.738993-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Sat, 9 Jul 2022 21:31:41 +0200 Message-ID: Subject: Re: [PATCH] Implement global ranges for all vrange types (SSA_NAME_RANGE_INFO). To: Jeff Law , "MacLeod, Andrew" Cc: gcc-patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2022 19:31:57 -0000 On Sat, Jul 9, 2022 at 6:16 PM Jeff Law via Gcc-patches wrote: > > > > On 7/6/2022 11:10 AM, Aldy Hernandez via Gcc-patches wrote: > > Currently SSA_NAME_RANGE_INFO only handles integer ranges, and loses > > half the precision in the process because its use of legacy > > value_range's. This patch rewrites all the SSA_NAME_RANGE_INFO > > (nonzero bits included) to use the recently contributed > > vrange_storage. With it, we'll be able to efficiently save any ranges > > supported by ranger in GC memory. Presently this will only be > > irange's, but shortly we'll add floating ranges and others to the mix. > > > > As per the discussion with the trailing_wide_ints adjustments and > > vrange_storage, we'll be able to save integer ranges with a maximum of > > 5 sub-ranges. This could be adjusted later if more sub-ranges are > > needed (unlikely). > > > > Since this is a behavior changing patch, I would like to take a few > > days for discussion, and commit early next week if all goes well. > > > > A few notes. > > > > First, we get rid of the SSA_NAME_ANTI_RANGE_P bit in the SSA_NAME > > since we store full resolution ranges. Perhaps it could be re-used > > for something else. > > > > The range_info_def struct is gone in favor of an opaque type handled > > by vrange_storage. It currently supports irange, but will support > > frange, prange, etc, in due time. > > > > From the looks of it, set_range_info was an update operation despite > > its name, as we improved the nonzero bits with each call, even though > > we clobbered the ranges. Presumably this was because doing a proper > > intersect of ranges lost information with the anti-range hack. We no > > longer have this limitation so now we formalize both set_range_info > > and set_nonzero_bits to an update operation. After all, we should > > never be losing information, but enhancing it whenever possible. This > > means, that if folks' finger-memory is not offended, as a follow-up, > > I'd like to rename set_nonzero_bits and set_range_info to update_*. > > > > I have kept the same global API we had in tree-ssanames.h, with the > > caveat that all set operations are now update as discussed above. > > > > There is a 2% performance penalty for evrp and a 3% penalty for VRP > > that is coincidentally in line with a previous improvement of the same > > amount in the vrange abstraction patchset. Interestingly, this > > penalty is mostly due to the wide int to tree dance we keep doing with > > irange and legacy. In a first draft of this patch where I was > > streaming trees directly, there was actually a small improvement > > instead. I hope to get some of the gain back when we move irange's to > > wide-ints, though I'm not in a hurry ;-). > > > > Tested and benchmarked on x86-64 Linux. I will also test on ppc64le > > before the final commit. > > > > Comments welcome. > > > > gcc/ChangeLog: > > > > * gimple-range.cc (gimple_ranger::export_global_ranges): Remove > > verification against legacy value_range. > > * tree-core.h (struct range_info_def): Remove. > > (struct irange_storage_slot): New. > > (struct tree_base): Remove SSA_NAME_ANTI_RANGE_P documentation. > > (struct tree_ssa_name): Add vrange_storage support. > > * tree-ssanames.cc (range_info_p): New. > > (range_info_fits_p): New. > > (range_info_alloc): New. > > (range_info_free): New. > > (range_info_get_range): New. > > (range_info_set_range): New. > > (set_range_info_raw): Remove. > > (set_range_info): Adjust to use vrange_storage. > > (set_nonzero_bits): Same. > > (get_nonzero_bits): Same. > > (duplicate_ssa_name_range_info): Remove overload taking > > value_range_kind. > > Rewrite tree overload to use vrange_storage. > > (duplicate_ssa_name_fn): Adjust to use vrange_storage. > > * tree-ssanames.h (struct range_info_def): Remove. > > (set_range_info): Adjust prototype to take vrange. > > * tree-vrp.cc (vrp_asserts::remove_range_assertions): Call > > duplicate_ssa_name_range_info. > > * tree.h (SSA_NAME_ANTI_RANGE_P): Remove. > > (SSA_NAME_RANGE_TYPE): Remove. > > * value-query.cc (get_ssa_name_range_info): Adjust to use > > vrange_storage. > > (update_global_range): Use int_range_max. > > (get_range_global): Remove as_a. > I'll be so happy once we don't have to keep doing the conversions > between the types. > > Anti-ranges no more! Yeah, it took a little longer than the 6 weeks Andrew had estimated originally :-P. Note that anti range kinda sorta still exist in two forms: a) If you use value_range, as it still uses the legacy stuff underneath. But any new consumers (evrp, DOM, etc), all pass an int_range or an int_range_max, so anyone who cares about ranges should never see an anti range. Later this cycle value_range will be typedefed to what is now Value_Range, which is an infinite precision range that works for all types the ranger supports. So anti-ranges here will die a quick death. b) There are some passes which still use the deprecated irange::kind(). This method will return VR_ANTI_RANGE if the range looks like this [-MIN, 123][567,+MAX]. But kind() is just a convenience function so that passes that have yet to be converted can still pretend they see anti-ranges. Underneath a non-legacy irange has no concept of an anti-range. Currently, I see the following passes still using the anti-range nonsense: gimple-array-bounds.cc gimple-ssa-warn-restrict.cc ipa-fnsummary.cc ipa-prop.cc pointer-query.cc tree-ssa-strlen.cc I don't understand the ipa-* stuff, so I never touched it. OTOH, the middle end warnings always break when you improve ranges so I left them alone. Aldy > > I've got no real concerns here. So unless someone objects, your plan is OK. > > jeff >