From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id D68D9385382E for ; Tue, 4 Oct 2022 14:34:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D68D9385382E 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-ej1-x62e.google.com with SMTP id f1so11805206ejw.7 for ; Tue, 04 Oct 2022 07:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date; bh=PmOSuXTnMzw0VR5nzEsp5V9sUukiwbQp0z7dYn+06Z4=; b=iViVgEPg2YpPkErLDzIH0l216BERm8fUJ+mqGGYRBKNhnKDg9wdVmt8K8vULekUjav C8QayRvXyufV7Z7ttIgeDqzQPBj79KAOiprnQ+nwF7dSluls9bao3NwOIE6h2mgHZ02K mKNF1uSiOQsHl34bMtQWe6PuybIfEVwXz0tyA7PFY2ve78FuTnXwOY4xZ6w8vL3XE9gM dfni/9Hf+FTrppVErBKdBCc13/V86dj0ZdBc7s9oHXROJY9hZJWwmfv5mcuLLmLc2dsc 1lG9X0BtCXS79IvjAy7xcL2LlaDYellve8hw+eCIXbHf1Po3Oy7vzwdEknGD9JUlSrFD THHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date; bh=PmOSuXTnMzw0VR5nzEsp5V9sUukiwbQp0z7dYn+06Z4=; b=4vuaSMrEQkn0JOWGqxSS+Hz6WbUSFFdPtdHuq5StDO7reBbCSXXgudxcvHjFTzscYY oxL42/sUtOExWSv32Jkhf772f5ilMR6TzjD5yX+qaYIH81XhxiF3AprgGgG2O8r54O5T ezo5NwWIoRqlDxh4zlFAOBzxTwJZmk/Rh6Mzamf2wlqXfv3I74LwLhczkJm/CDgXSb2h Ucg/ApqceB0ZqimZOKrEDs3JBpdP8qO9efvmJV9Ciu2UHPlKeZ8G55k2WlSA4Ri+X92R TJPVvQEDfaDEnsEX89GPwD6VLOctdJDrQCqPCg2kWCJistC+zUumusdb/rv6phdrv/mp zkJA== X-Gm-Message-State: ACrzQf2ckQftsmV7WazrZX1KKW7qBtXzqtZPUvBrRv5RyMYcCjDFl4zY JOVaZSPOBgqbYCZNy4LHNVpFBUVppeUcmg== X-Google-Smtp-Source: AMsMyM4QGX2I/3hs8eMbnPH6Yj62Hl57p75p0Lf2rGv3SjKgwm4DZ1nonV8m3KdHKqY1zfZHMNo1Ug== X-Received: by 2002:a17:907:6d03:b0:782:abba:936c with SMTP id sa3-20020a1709076d0300b00782abba936cmr19543712ejc.758.1664894049321; Tue, 04 Oct 2022 07:34:09 -0700 (PDT) Received: from smtpclient.apple (dynamic-077-004-088-060.77.4.pool.telefonica.de. [77.4.88.60]) by smtp.gmail.com with ESMTPSA id 10-20020a170906308a00b0078cf8a743d6sm1975940ejv.100.2022.10.04.07.34.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Oct 2022 07:34:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: [COMMITTED] Convert nonzero mask in irange to wide_int. Date: Tue, 4 Oct 2022 16:34:07 +0200 Message-Id: <07FCA378-7E86-4E06-B506-FED0C60CE31C@gmail.com> References: Cc: Andrew MacLeod , GCC patches In-Reply-To: To: Aldy Hernandez X-Mailer: iPhone Mail (19H12) X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: > Am 04.10.2022 um 16:30 schrieb Aldy Hernandez : >=20 > =EF=BB=BFOn Tue, Oct 4, 2022 at 3:27 PM Andrew MacLeod wrote: >>=20 >>=20 >>> On 10/4/22 08:13, Aldy Hernandez via Gcc-patches wrote: >>>> On Tue, Oct 4, 2022, 13:28 Aldy Hernandez wrote: >>>=20 >>>> On Tue, Oct 4, 2022 at 9:55 AM Richard Biener >>>> wrote: >>>>>=20 >>>>> Am 04.10.2022 um 09:36 schrieb Aldy Hernandez via Gcc-patches < >>>> gcc-patches@gcc.gnu.org>: >>>>>> =EF=BB=BFThe reason the nonzero mask was kept in a tree was basically= inertia, >>>>>> as everything in irange is a tree. However, there's no need to keep >>>>>> it in a tree, as the conversions to and from wide ints are very >>>>>> annoying. That, plus special casing NULL masks to be -1 is prone >>>>>> to error. >>>>>>=20 >>>>>> I have not only rewritten all the uses to assume a wide int, but >>>>>> have corrected a few places where we weren't propagating the masks, o= r >>>>>> rather pessimizing them to -1. This will become more important in >>>>>> upcoming patches where we make better use of the masks. >>>>>>=20 >>>>>> Performance testing shows a trivial improvement in VRP, as things lik= e >>>>>> irange::contains_p() are tied to a tree. Ughh, can't wait for trees i= n >>>>>> iranges to go away. >>>>> You want trailing wide int storage though. A wide_int is quite large.= >>>> Absolutely, this is only for short term storage. Any time we need >>>> long term storage, say global ranges in SSA_NAME_RANGE_INFO, we go >>>> through vrange_storage which will stream things in a more memory >>>> efficient manner. For irange, vrange_storage will stream all the >>>> sub-ranges, including the nonzero bitmask which is the first entry in >>>> such storage, as trailing_wide_ints. >>>>=20 >>>> See irange_storage_slot to see how it lives in GC memory. >>>>=20 >>> That being said, the ranger's internal cache uses iranges, albeit with a= >>> squished down number of subranges (the minimum amount to represent the >>> range). So each cache entry will now be bigger by the difference betwee= n >>> one tree and one wide int. >>>=20 >>> I wonder if we should change the cache to use vrange_storage. If not now= , >>> then when we convert all the subranges to wide ints. >>>=20 >>> Of course, the memory pressure of the cache is not nearly as problematic= as >>> SSA_NAME_RANGE_INFO. The cache only stores names it cares about. >>=20 >> Rangers cache can be a memory bottleneck in pathological cases.. >> Certainly not as bad as it use to be, but I'm sure it can still be >> problematic. Its suppose to be a memory efficient representation >> because of that. The cache can have an entry for any live ssa-name >> (which means all of them at some point in the IL) multiplied by a factor >> involving the number of dominator blocks and outgoing edges ranges are >> calculated on. So while SSA_NAME_RANGE_INFO is a linear thing, the >> cache lies somewhere between a logarithmic and exponential factor based >> on the CFG size. >=20 > Hmmm, perhaps the ultimate goal here should be to convert the cache to > use vrange_storage, which uses trailing wide ints for all of the end > points plus the masks (known_ones included for the next release). >=20 >>=20 >> if you are growing the common cases of 1 to 2 endpoints to more than >> double in size (and most of the time not be needed), that would not be >> very appealing :-P If we have any wide-ints, they would need to be a >> memory efficient version. The Cache uses an irange_allocator, which is >> suppose to provide a memory efficient objects.. hence why it trims the >> number of ranges down to only what is needed. It seems like a trailing >> wide-Int might be in order based on that.. >>=20 >> Andrew >>=20 >>=20 >> PS. which will be more problematic if you eventually introduce a >> known_ones wide_int. I thought the mask tracking was/could be >> something simple like HOST_WIDE_INT.. then you only tracks masks in >> types up to the size of a HOST_WIDE_INT. then storage and masking is >> all trivial without going thru a wide_int. Is that not so/possible? >=20 > That's certainly easy and cheaper to do. The hard part was fixing all > the places where we weren't keeping the masks up to date, and that's > done (sans any bugs ;-)). >=20 > Can we get consensus here on only tracking masks for type sizes less > than HOST_WIDE_INT? I'd hate to do all the work only to realize we > need to track 512 bit masks on a 32-bit host cross :-). 64bits are not enough, 128 might be. But there=E2=80=99s trailing wide int s= torage so I don=E2=80=99t see the point in restricting ourselves? > Aldy >=20