From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id E34A33857837 for ; Fri, 28 Oct 2022 07:01:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E34A33857837 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-x630.google.com with SMTP id n12so10771445eja.11 for ; Fri, 28 Oct 2022 00:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hpRuwo0PJ5Nt3InhyIrdwzethyb03DJr8X0OqY6n374=; b=ddACRhErrUw8rz+JjMxfbZArmEJfDm87V1BRj/KAhdAY5aEPjJvn6lnQD0QQpI6QJI 6buRAGPm46rvkrmAVh0GshoEyNznG+WoqYYJdeY1E7QYyUGDz9sXZUcPCTq1D0onvLpV M1rwR0ytooRJSqsDN3bxyQ2mTe5LGlNbG5ADeYvJ9Uz26bMQNPjH2d+32rC8bEUA3YP9 kFvXjiW0Iw2Qy3LS1k6EeBHuaOatKMmRxlIin2NBqJ1RhuYwDGz3JmtXeHBHmCYRdnfl huxzCqPUFt0JTQn3Fbc3SQBYWGnoZQd6J2IV3gVtrdgxQmy27cssT+gty5IJZfIsGt3u XydQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=hpRuwo0PJ5Nt3InhyIrdwzethyb03DJr8X0OqY6n374=; b=aQbvr4IdAPnci5PnyiTkhBkuJsSxVQho2w/wl8NNQAfIO2aW9pADCgk69sPjmoiT5v GJPGNfYibtf+6dX15BJ7TuTYXbm6Ijb8CfO6U+tB4Tm0GQTIiWn1zbeotestTP0HHvWS bgu92jyST+Xwgr4dLeK59qH2bqrrnjU6ZxPvD3I0pQ5Wf6lldppgm+/vw2TaMo8KvE0Y fXl/nWMQPKVCW2TJxsETci1HlhKkMf7YSU3P8FBkIMwZJjS7yCIBu2GIHHhRTe2uiLTH 7epoGR8LKZwyZQHai4zM9bCrwGq84DsKk0CV4kc61cYs4JHRkB4kxNJvR3MnEOGuoMI8 tbow== X-Gm-Message-State: ACrzQf1jS8UtYDYQt2KUNHRb4FMxQAn5X9+X2man5p8Bo6C+t49ljv3D yOmH39/YJSmBkUX9zHo+0IRt9e5MtUVxptcBe9g= X-Google-Smtp-Source: AMsMyM6IWTSS0/D8drUniJvKUTzqsDnmUBCfl6TttvrUL2ems01VXoNm360BGxYyiJI1BhrzEKOmDu/wC6I6jhyXO1Y= X-Received: by 2002:a17:907:8a27:b0:78e:274e:9235 with SMTP id sc39-20020a1709078a2700b0078e274e9235mr45784416ejc.754.1666940465743; Fri, 28 Oct 2022 00:01:05 -0700 (PDT) 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, 28 Oct 2022 09:00:53 +0200 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" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 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, 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 a= re > 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? The function tries to compensate for that, maybe you can point out where it goes wrong? That is, at the end it adjusts cost and complexity based on what it scrapped before, maybe that is just a bit incomplete? Note the original author of this is not available so it would help (maybe also yourself) to walk through the function with a specific candidate / use where you think the complexity (or cost) is wrong? > Regards, > Dimitrije > > > From: Jeff Law > Sent: Friday, October 28, 2022 1:02 AM > To: Dimitrije Milosevic ; gcc-patches@gcc= .gnu.org > Cc: Djordje Todorovic > Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost compl= exity. > > > On 10/21/22 07:52, Dimitrije Milosevic wrote: > > From: Dimitrije Milo=C5=A1evi=C4=87 > > > > This patch reverts the computation of address cost complexity > > to the legacy one. After f9f69dd, complexity is calculated > > using the valid_mem_ref_p target hook. Architectures like > > Mips only allow BASE + OFFSET addressing modes, which in turn > > prevents the calculation of complexity for other addressing > > modes, resulting in non-optimal candidate selection. > > > > gcc/ChangeLog: > > > > * tree-ssa-address.cc (multiplier_allowed_in_address_p): Change > > to non-static. > > * tree-ssa-address.h (multiplier_allowed_in_address_p): Declare. > > * tree-ssa-loop-ivopts.cc (compute_symbol_and_var_present): Rein= troduce. > > (compute_min_and_max_offset): Likewise. > > (get_address_cost): Revert > > complexity calculation. > > 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? > > > jeff >