From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 6D5C83857C4A for ; Mon, 7 Nov 2022 13:35:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6D5C83857C4A 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-x636.google.com with SMTP id y14so30121161ejd.9 for ; Mon, 07 Nov 2022 05:35:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Ne99P01JfYg0ErRCXRPvi/m2fdvFVMom2iQVJdpl8lM=; b=BkM/Flemr2Wd4cYDnvDioFElz3aMmnRofVA8zShQs7TdNVIDKrj2iFz3Np4jrt/Zu1 7aawSgqJtvx0Vk1+aplKw9002i5Nw07EViEWbcyDCqVInRCskOXMTJwHLut1W8SOEYqw qnC7rtesVmUA5fFneeO+i9R+/yIhSOR2pWpUWpQlb/xNPxMG05UFrmFYCJ7qoPuwZqc9 3Gyp4t8GzwJLMnooN1vBTKtXRzLLA0GogoyrDYjHGvLDUhm5GMsHtyf8tsUXaZRxHI25 EN/0wYHoZ0HMEPfTyNzlXtGFGkrT1DkCLijb74f3GkuwET0qtypTgem1Bwtnkb0qcz+U qiAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ne99P01JfYg0ErRCXRPvi/m2fdvFVMom2iQVJdpl8lM=; b=kWuefURl9Jm+56/h03UTwJLWcD9p2lyTu79I5Aowtwwzk9OUIc4B0a5ulhcod1T0gb +pi2dDReb+yuIrWx26roMSSp9H0F3t77cnyyZV9fTKnGKnGQOtUKfmKo+UpPKmE+os3i qETvKKtGzgYgyJr/5juO9R0iHIPs1fmDf+rH5XKVwgbmtYI1BmsLZB3HTwhot7eDlyWM erYuMVOvcFAJlRASDUSM516bxxEAQS+5wDMIi62q80QbCiSjxrJLYFAdnD4uycPOMwkN MH4BuIlfuBfjiAtrHeV7A5YqTtwt+0hjFre4Anx7KhRyGU+NTVa9aCrc9Nb6fSspo0Uq BWJw== X-Gm-Message-State: ANoB5pm8yxdo8QD0gPLl04ItklnimAt/OxDctRHl88YA4GvcwFtVjvgW HIE5KKNqVc2uluCYb87/k9atmvuuJLSkRKibf2w= X-Google-Smtp-Source: AA0mqf6nzWP3aB2IuKC69EcWdVfVGP+Dw3w/BxDKP0uZd5qiGwwYwVnbIFu6RD0NYyV1Pm+xep14aKMD8Klj4X02Z/8= X-Received: by 2002:a17:907:778a:b0:7ae:743c:61c1 with SMTP id ky10-20020a170907778a00b007ae743c61c1mr1688165ejc.511.1667828140107; Mon, 07 Nov 2022 05:35:40 -0800 (PST) MIME-Version: 1.0 References: <20221021135203.626255-1-dimitrije.milosevic@syrmia.com> <20221021135203.626255-2-dimitrije.milosevic@syrmia.com> <3c50de1f-c00b-9f8a-a604-a71bc546f1c2@gmail.com> In-Reply-To: From: Richard Biener Date: Mon, 7 Nov 2022 14:35:27 +0100 Message-ID: Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost complexity. To: Dimitrije Milosevic Cc: Jeff Law , "gcc-patches@gcc.gnu.org" , Djordje Todorovic Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 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: On Wed, Nov 2, 2022 at 9:40 AM Dimitrije Milosevic wrote: > > Hi Jeff, > > > This is exactly what I was trying to get to. If the addressing mode > > isn't supported, then we shouldn't be picking it as a candidate. If it > > is, then we've probably got a problem somewhere else in this code and > > this patch is likely papering over it. I'm not sure this is accurate but at least the cost of using an unsupported addressing mode should be at least that of the compensating code to mangle it to a supported form. > I'll take a deeper look into the candidate selection algorithm then. Will > get back to you. Thanks - as said the unfortunate situation is that both the original author and the one who did the last bigger reworks of the code are gone. Richard. > Regards, > Dimitrije > > ________________________________________ > From: Jeff Law > Sent: Tuesday, November 1, 2022 7:46 PM > To: Richard Biener; Dimitrije Milosevic > Cc: gcc-patches@gcc.gnu.org; Djordje Todorovic > Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost complexity. > > > On 10/28/22 01:00, Richard Biener wrote: > > On Fri, Oct 28, 2022 at 8:43 AM Dimitrije Milosevic > > wrote: > >> Hi Jeff, > >> > >>> THe part I don't understand is, if you only have BASE+OFF, why does > >>> preventing the calculation of more complex addressing modes matter? ie, > >>> what's the point of computing the cost of something like base + off + > >>> scaled index when the target can't utilize it? > >> Well, the complexities of all addressing modes other than BASE + OFFSET are > >> equal to 0. For targets like Mips, which only has BASE + OFFSET, it would still > >> be more complex to use a candidate with BASE + INDEX << SCALE + OFFSET > >> than a candidate with BASE + INDEX, for example, as it has to compensate > >> the lack of other addressing modes somehow. If complexities for both of > >> those are equal to 0, in cases where complexities decide which candidate is > >> to be chosen, a more complex candidate may be picked. > > But something is wrong then - it shouldn't ever pick a candidate with > > an addressing > > mode that isn't supported? So you say that the cost of expressing > > 'BASE + INDEX << SCALE + OFFSET' as 'BASE + OFFSET' is not computed > > accurately? > > This is exactly what I was trying to get to. If the addressing mode > isn't supported, then we shouldn't be picking it as a candidate. If it > is, then we've probably got a problem somewhere else in this code and > this patch is likely papering over it. > > > Jeff >