From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=mO/z=73=kernel.crashing.org=segher@sourceware.org>
Received: from gate.crashing.org (gate.crashing.org [63.228.1.57])
	by sourceware.org (Postfix) with ESMTP id E09A83858C54
	for <gcc-patches@gcc.gnu.org>; Tue,  4 Apr 2023 15:41:30 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E09A83858C54
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 334FeU46013254;
	Tue, 4 Apr 2023 10:40:30 -0500
Received: (from segher@localhost)
	by gate.crashing.org (8.14.1/8.14.1/Submit) id 334FeTho013253;
	Tue, 4 Apr 2023 10:40:29 -0500
X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f
Date: Tue, 4 Apr 2023 10:40:29 -0500
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Ajit Agarwal <aagarwa1@linux.ibm.com>,
        gcc-patches <gcc-patches@gcc.gnu.org>,
        Peter Bergner <bergner@linux.ibm.com>,
        Jeff Law <jeffreyalaw@gmail.com>,
        Richard Biener <richard.guenther@gmail.com>,
        Raphael Zinsly <rzinsly@ventanamicro.com>
Subject: Re: [PATCH] ree: Improvement of ree pass for rs6000 target.
Message-ID: <20230404154029.GE25951@gate.crashing.org>
References: <20d786e3-2d9d-89bd-8112-8549c24678c3@linux.ibm.com> <ZCwPyv1xMYvAwkGX@tucnak> <20230404151923.GD25951@gate.crashing.org> <ZCxBoqH9BqHTaVaj@tucnak>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZCxBoqH9BqHTaVaj@tucnak>
User-Agent: Mutt/1.4.2.3i
X-Spam-Status: No, score=-2.8 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: <gcc-patches.gcc.gnu.org>

On Tue, Apr 04, 2023 at 05:26:26PM +0200, Jakub Jelinek wrote:
> On Tue, Apr 04, 2023 at 10:19:23AM -0500, Segher Boessenkool wrote:
> > > > +    /* Enable -free for zero extension and sign extension elimination.*/
> > > > +    { OPT_LEVELS_2_PLUS, OPT_free, NULL, 1 },
> > > 
> > > I believe the options should be sorted by the OPT_LEVEL* they are given.
> > 
> > If that is true, that rule is violated all over the place already.  It
> > doesn't make much sense anyway, the OPT_LEVEL* have no complete ordering
> > at all.  But, yeah, -O2 stuff after the -O1 stuff makes sense, and we do
> > have such a partial ordering now.
> 
> At least default_options_table sorts stuff like that.  Sure, the larger
> the table it is, the more it is important to be able to see clearly what
> each level enables.

And ours is 16 lines including whitespace.  But yeah, and the
presentation can be improved other ways as well.

The default_options_table has in order:
    /* -O1 and -Og optimizations.  */
    /* -O1 (and not -Og) optimizations.  */
    /* -O2 and -Os optimizations.  */
    /* -O2 and above optimizations, but not -Os or -Og.  */
    /* -O3 and -Os optimizations.  */
    /* -O3 optimizations.  */
    /* -O3 parameters.  */
    /* -Ofast adds optimizations to -O3.  */
(and no OPT_LEVELS_ALL at all, the most common for us and probably
most other targets.  Logically these come first, if ordering by opt
level).

Either way, yes we should have some grouping.  Not the same as the
above, but something that does make some sense :-)


Segher