From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by sourceware.org (Postfix) with ESMTPS id 56BCD3851345 for ; Fri, 16 Dec 2022 11:59:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 56BCD3851345 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-lf1-x12a.google.com with SMTP id b3so3167385lfv.2 for ; Fri, 16 Dec 2022 03:59:04 -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=JI6pgCF5qWXfmfQBpj586j8A8TyVdHrXNOorFpv7czg=; b=MmmxspeNbtOorIN09QIU+es7De5yY4HIsqIFGt+axqEfhqHDe9rLjLyM5ejjJ6uzPr VPbYXTrrDqAjuxZsNGhD8GZDfkNks/bZpF8YMeTAs7a/2SdDngis1YDjtyyFo1TG6bUg kUeNqr6p4TWpnXVvONfzC75XQhnXkH3PMmpUeMLRrpMndheqItlcWP5myzdDc9Opbagy HcoauaiFOubRYTHWC/7rsAx2NbxEoQlyVRuzZmRGsD/RZktWFJi53JS5nBohLEZRxFr3 yCE9RrvXHdGXG/jOi66DX35fxPF2PuW7Ei3MHJ2v7fqdSFMc0qD2+o6BaLK11JFjiDzS 4HcA== 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=JI6pgCF5qWXfmfQBpj586j8A8TyVdHrXNOorFpv7czg=; b=XfsGtX6vj4Ha897bbzlPrF/faJg9IEZ82ifiUCqdlNIX3pA/ZnYYQqnsyoSKU4CETs 17u8AG3OiIqUtnMnIQ20XCaVzC/tsOCQtBa9inVOs4nkIWjYMPLNn6mqlBEDTAN+fHXw KRiOzNYNLY+i1PJdpws/p3Uvqq+Mw04fwDoRdvpqACgHF5PcT2AejP4wF53svLO7XvYK /thaG9nvH+0KslouPQT5YXi77mQsTFFDhYUNpxxHbMup4p+JuzRoMmGeklI9BUDqvI+u cKCD00eqNkEOIvvOIPy4HP3HrJEJdewgq8s1JCH27496ggA1oqCSbFNbpZRhh1P1jZ4o cXgA== X-Gm-Message-State: ANoB5pkaiS9N7xpUv4RRtQ9ZTt/0WPE8dasg5+bTxyoLEmftzjOBj7HI 8SbkOuzYhCP/Mw1hqNej8K6Xoct75dC/95eHWsk= X-Google-Smtp-Source: AA0mqf4wlmIu1XuI01JPZgNtj8Zc0hX596HXd1loeWhxv510XurD+ftXwegMKe0t6PL12kItN0b4jo4RZit5Iey4obg= X-Received: by 2002:ac2:4c42:0:b0:4a5:bf09:a700 with SMTP id o2-20020ac24c42000000b004a5bf09a700mr26263171lfk.656.1671191942391; Fri, 16 Dec 2022 03:59:02 -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: Fri, 16 Dec 2022 12:58:49 +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.0 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 Fri, Dec 16, 2022 at 12:37 PM Dimitrije Milosevic wrote: > > > Hi Richard, > > > The only documentation on complexity I find is > > > > int64_t cost; /* The runtime cost. */ > > unsigned complexity; /* The estimate of the complexity of the code for > > the computation (in no concrete units -- > > complexity field should be larger for more > > complex expressions and addressing modes). */ > > > > and complexity is used as tie-breaker only when cost is equal. Given that > > shouldn't unsupported addressing modes have higher complexity? I'll note > > that there's nothing "unsupported", each "unsupported" address computation > > is lowered into supported pieces. "unsupported" maybe means that > > "cost" isn't fully covered by address-cost and compensation stmts might > > be costed in quantities not fully compatible with that? > > Correct, that's what I was aiming for initially - before f9f69dd that was the case, > "unsupported" addressing modes had higher complexities. > Also, that's what I meant by "unsupported" as well, thanks. > > > That said, "complexity" seems to only complicate things :/ We do have the > > tie-breaker on preferring less IVs. complexity was added in > > r0-85562-g6e8c65f6621fb0 as part of fixing PR34711. > > I agree that the complexity part is just (kind of) out there, not really strongly > defined. I'm not sure how to feel about merging complexity into the cost part > of an address cost, though. > > > If it's really only about the "complexity" value then each > > compensation step should > > add to the complexity? > > That could be the way to go. Also worth verifying is that we compensate for > each case of an unsupported addressing mode. Yes. Also given complexity is only a tie-breaker we should cost the compensation somehow, but then complexity doesn't look necessary ... Meh. > > Kind regards, > Dimitrije > > From: Richard Biener > Sent: Friday, December 16, 2022 10:58 AM > To: Dimitrije Milosevic > Cc: Jeff Law ; gcc-patches@gcc.gnu.org ; Djordje Todorovic > Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost complexity. > > On Thu, Dec 15, 2022 at 4:26 PM Dimitrije Milosevic > wrote: > > > > Hi Richard, > > > > Sorry for the delayed response, I couldn't find the time to fully focus on this topic. > > > > > 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'm pretty sure IVOPTS does not filter out candidates which aren't supported by > > the target architecture. It does, however, adjust the cost for a subset of those. > > The adjustment code modifies only the cost part of the address cost (which > > consists of a cost and a complexity). > > Having said this, I'd propose two approaches: > > 1. Cover all cases of unsupported addressing modes (if needed, I'm not entirely > > sure they aren't already covered), leaving complexity for unsupported > > addressing modes zero. > > The only documentation on complexity I find is > > int64_t cost; /* The runtime cost. */ > unsigned complexity; /* The estimate of the complexity of the code for > the computation (in no concrete units -- > complexity field should be larger for more > complex expressions and addressing modes). */ > > and complexity is used as tie-breaker only when cost is equal. Given that > shouldn't unsupported addressing modes have higher complexity? I'll note > that there's nothing "unsupported", each "unsupported" address computation > is lowered into supported pieces. "unsupported" maybe means that > "cost" isn't fully covered by address-cost and compensation stmts might > be costed in quantities not fully compatible with that? > > That said, "complexity" seems to only complicate things :/ We do have the > tie-breaker on prefering less IVs. complexity was added in > r0-85562-g6e8c65f6621fb0 as part of fixing PR34711. > > > 2. Revert the complexity calculation (which my initial patch does), leaving > > everything else as it is. > > 3. A combination of both - if the control path gets into the adjustment code, we > > use the reverted complexity calculation. > > If it's really only about the "complexity" value then each > compensation step should > add to the complexity? > > > I'd love to get feedback regarding this, so I could focus on a concrete approach. > > > > Kind regards, > > Dimitrije > > > > From: Richard Biener > > Sent: Monday, November 7, 2022 2:35 PM > > To: Dimitrije Milosevic > > Cc: Jeff Law ; gcc-patches@gcc.gnu.org ; Djordje Todorovic > > Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost complexity. > > > > 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 > > >