From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id 0DF0E3830FDF for ; Fri, 16 Dec 2022 09:58:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0DF0E3830FDF 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-lj1-x22f.google.com with SMTP id v11so1584999ljk.12 for ; Fri, 16 Dec 2022 01:58:47 -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=Amxsd5tbdWx7UdMwwgd0IlZQ+bOrRZAZ2I88XgwfEsI=; b=CW/P1feWPQFI/vKHwGxHLksl2M03oP7EGTfNfPy3SG0eww3xpX2uAUI2XVIsizJvg+ i/FZhYyXe0dNgxRC7LOs565QzxyzU9VXKiElrbOZpuVF0E+eHj2Ipk/FSS8ymc0NiPPW XUt4+q8+k28ccFDuThdPS5Lpd+j7/jiAdqNTXZyZrMvgrENR1A+Qnl5YDJefPOqQBGU9 0Lys3ucbYf9ldMMS4rQlYTudKS2ZssOxB8Wr6kIIKGKdX1KmvePgHJ4RgkaXiGulfpz5 jOmPJlJbwwRqij3qrQTmCtfGgkdXqzLtNDchRQMb3LbujVlzSUtpNH5Am61miBYwZj9e 9/YA== 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=Amxsd5tbdWx7UdMwwgd0IlZQ+bOrRZAZ2I88XgwfEsI=; b=TTLfUPs5XuI+z3UInYBnmKkRIX6p3lu3mumreq8ME8l/TuJrepYdSpAFOFSrrZ22qe 5yzOv9d3Lw2Csi0NVzuFbnam3ifKBcUsKCnYzrj9BqX4Y2MI+x/7AyaO669xzQw7CrGH 3s3frG8d9GkVytQz/eOH3zNdtRnHoHIjK8h+cmqs0hktkR6p9mNouR3oT+p7LYVTprvo 2Q90wkkKjCdstDQIzhZbcOE5vLVgO0iH4Xd7gBvqEId/pQrh8wxV7EVkTHRv0NxVERuB koRoJwJItF4wzpodFL2YUKKS+TsKzPPZOBI0hFLq8CEzgIb7R31501spb0sjuqCE8LiM OVrQ== X-Gm-Message-State: ANoB5pn4qkPTIFF4g2070Wz+mCrMTSQ+AJrJ6VnBwfXUNaZ3X46SaADk YDm9zPwitLF25v3sYSBspbxCnNaF/TnkDxqucwg= X-Google-Smtp-Source: AA0mqf79b0KU0JLNly4OcJhaK/sflnyovZmvT04OSzw7wsdT6sWMQ7BtW/ZOOT9CW+XFM549xuT4BYljFdssc/meESk= X-Received: by 2002:a2e:b5b3:0:b0:279:86ec:a686 with SMTP id f19-20020a2eb5b3000000b0027986eca686mr21289853ljn.399.1671184726378; Fri, 16 Dec 2022 01:58:46 -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 10:58:33 +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.4 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 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 > >