From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=bl30=BT=orcam.me.uk=macro@sourceware.org>
Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34])
	by sourceware.org (Postfix) with ESMTP id 21C7E3858D20
	for <gcc-patches@gcc.gnu.org>; Tue, 30 May 2023 11:44:15 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 21C7E3858D20
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk
Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk
Received: by angie.orcam.me.uk (Postfix, from userid 500)
	id 46E4A92009C; Tue, 30 May 2023 13:44:14 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by angie.orcam.me.uk (Postfix) with ESMTP id 40FE792009B;
	Tue, 30 May 2023 12:44:14 +0100 (BST)
Date: Tue, 30 May 2023 12:44:14 +0100 (BST)
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: YunQiang Su <syq@debian.org>
cc: Jeff Law <jeffreyalaw@gmail.com>, YunQiang Su <yunqiang.su@cipunited.com>, 
    gcc-patches@gcc.gnu.org, jiaxun.yang@flygoat.com, 
    richard.sandiford@arm.com
Subject: Re: [PATCH] MIPS: don't expand large block move
In-Reply-To: <CAKcpw6Wgx3R5A31fnEAH_0+dPK4_Yw6MwCxODPyUth5rVbcK_w@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2305300208110.25569@angie.orcam.me.uk>
References: <20230519061152.3154332-1-yunqiang.su@cipunited.com> <62638b5e-d9a5-0ede-0642-ea363d23d055@gmail.com> <alpine.DEB.2.21.2305192000570.50034@angie.orcam.me.uk> <CAKcpw6Wgx3R5A31fnEAH_0+dPK4_Yw6MwCxODPyUth5rVbcK_w@mail.gmail.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-1163.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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 Wed, 24 May 2023, YunQiang Su wrote:

> > or even:
> >
> >       if (INTVAL (length) <= MIPS_MAX_MOVE_BYTES_STRAIGHT)
> >         ...
> >       else if (INTVAL (length) < 64 && optimize)
> >         ...
> >
> 
> I don't think this is a good option, since somebody may add some code,
> and may break our logic.

 There's no need to plan ahead for changes, which may never happen.  As it 
stands reading through such flattened code here requires one step less to 
analyse as there's one nested level and one exit point less here.  If more 
cases have to be added in the future, then whoever needs them will make 
any necessary adjustments to the structure (assuming minimal understanding 
how code works, which I think is a reasonable requirement for working on a 
compiler).

  Maciej