From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id D01A43856DC0 for ; Fri, 21 Oct 2022 16:46:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D01A43856DC0 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 29LGjYeF002347; Fri, 21 Oct 2022 11:45:34 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 29LGjXKQ002346; Fri, 21 Oct 2022 11:45:33 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 21 Oct 2022 11:45:33 -0500 From: Segher Boessenkool To: Aldy Hernandez Cc: GCC patches Subject: Re: [PATCH] Rename nonzero_bits to known_zero_bits. Message-ID: <20221021164533.GW25951@gate.crashing.org> References: <20221021131426.308205-1-aldyh@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221021131426.308205-1-aldyh@redhat.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi! On Fri, Oct 21, 2022 at 03:14:26PM +0200, Aldy Hernandez via Gcc-patches wrote: > The name nonzero_bits is confusing. We're not tracking nonzero bits. > We're tracking known-zero bits, or at the worst we're tracking "maye > nonzero bits". But really, the only thing we're sure about in the > "nonzero" bits are the bits that are zero, which are known to be 0. > We're not tracking nonzero bits. Indeed. > I know we've been carrying around this name forever, but the fact that > both of the maintainers of the code *HATE* it, should be telling. > Also, we'd also like to track known-one bits in the irange, so it's > best to keep the nomenclature consistent. And that as well. However: > * asan.cc (handle_builtin_alloca): Rename *nonzero* to *known_zero*. Our "nonzero" means "not known to be zero", not "known to be zero", so this renaming makes it worse than it was. Rename it to "not_known_zero", make that a thin wrapper around a new "known_zero", and slowly get rid of not_known_zero? > --- a/gcc/asan.cc > +++ b/gcc/asan.cc > @@ -816,7 +816,7 @@ handle_builtin_alloca (gcall *call, gimple_stmt_iterator *iter) > tree redzone_size = build_int_cst (size_type_node, ASAN_RED_ZONE_SIZE); > > /* Extract lower bits from old_size. */ > - wide_int size_nonzero_bits = get_nonzero_bits (old_size); > + wide_int size_nonzero_bits = get_known_zero_bits (old_size); Such variables should also be renamed :-( Segher