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 984153858D28 for ; Tue, 29 Nov 2022 00:37:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 984153858D28 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 2AT0aB7Q021346; Mon, 28 Nov 2022 18:36:12 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 2AT0aB8E021345; Mon, 28 Nov 2022 18:36:11 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 28 Nov 2022 18:36:11 -0600 From: Segher Boessenkool To: David Malcolm Cc: Charlie Sale , gcc-patches@gcc.gnu.org, Richard Biener , jakub@redhat.com Subject: Re: [PATCH] rtl: add predicates for addition, subtraction & multiplication Message-ID: <20221129003611.GR25951@gate.crashing.org> References: <20221127021613.432881-1-softwaresale01@gmail.com> <0049ac9c21bb07bc12b7670a51ca07e18a38721a.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0049ac9c21bb07bc12b7670a51ca07e18a38721a.camel@redhat.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.0 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: On Sun, Nov 27, 2022 at 09:21:00AM -0500, David Malcolm via Gcc-patches wrote: > We're currently in "stage 3" of GCC 13 development, which means that > we're focusing on bug-fixing, rather than cleanups and feature work. > Though exceptions can be made for low-risk work, at the discretion of > the release managers; I've taken the liberty of CCing them. Such global changes are incomnvenient for people who have touched any of that code in their own patches. If we really want to do that it should be done early in stage 1 (when everything is broken for everyone anyway), and should be agreed on beforehand, or really, should only be done for obvious improvements. This is not an obvious improvement. > > All existings tests did pass. I have never seen a single target where all existing tests passed. What we usually do is "same failures before and after the patch" :-) > RTL is an aspect of the compiler that tends to have the most per-target > differences, so it's especially important to be precise about which > target(s) you built and tested on. Not that that should matter at all for patches that do not actually change anything, like this one should be: it should only change notation. That is in the nature of helper functions and helper macros. > > Like I said, this is my first patch.  > > We're sometimes not as welcoming to newcomers as we could be, so please > bear with us. Let me know if anything in this email is unclear. x2 from me! > As noted in another reply, there are lots of places in the code where > the patch touches lines that it doesn't need to: generally formatting > and whitespace changes. > > We have over 30 years of source history which we sometimes need to look > back on, and RTL is some of the oldest code in the compiler, so we want > to minimize "churn" to keep tools like "git blame" useful. Not to mention that many of those changes violated our coding style, or even look like an automated formatter going haywire. And, of course, such changes should be separate patches, if done at all! Segher