From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id 0DA73385801C for ; Tue, 1 Nov 2022 18:46:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0DA73385801C 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-pg1-x52f.google.com with SMTP id r18so14151222pgr.12 for ; Tue, 01 Nov 2022 11:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=M74KTmB/MatPNfxcdH4nAkhD59nOIZWnQ7bcTBVwAuw=; b=LrphtCnudSLjU0mUJJd6rY7svFGdIi5HNhv2KKfvCi2JiI8sJfBPkp+9+bCo8ESPek 6rWtyCBw4xhNCT8JAOJqyUZrmlDjel0LJeEeFpGfQcqp5fng7+kq4cjXUbn58KJ9e+1U DmHqW8GN95EkaJIIFcm1X014jejdDtmXVZJNQqFD6a85QK/rQ1FULl0YrnYCMxZIIVTM dEhJgmH3khq7J2q347+/so4dhmNCdFUsNEeF3SpOu8M6gn6FzO8oAmEJgwOL1qHXQGN9 04z3gEtqcgzrrjWc9SUigoGfBfDeVjvvOBQ8Pp/bEwAYPwdcoxjFAoSeoMk9Yzt7B3F4 4yLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=M74KTmB/MatPNfxcdH4nAkhD59nOIZWnQ7bcTBVwAuw=; b=p1FvvZ78xOyfm/wCju2uMkKV4NvS2e5cCRZeL8KwiISwNXX+aUipaIFMqlZFiPplcy R4CjtbydkZ92A9bV75M+S3w0UbUpMLtfVOjjCFJ91XvrnhfAIz8kxj9B4qDXBkssDHhV MQaAJo07Iix6SkwwnEHHhdl1PnbQLw6PKSAZr8jcV6FpuCcJRsWXCg2+blWst537J6xi UbTbU6wcazPAxQkNYlwv8QfPcX0bGClv/uycdKErfyg1iq0ev41EimluxhadCubgTwMy ScmB/lQCR3RiIJdn6ydx+hpzp/Z15wbGFof12Kn0qPWy+U4PM9ZIay5Z3lsPMbkU48VL EVTA== X-Gm-Message-State: ACrzQf2Z7XAgqIMWgUhMkIcgbUWFI1NAOGzjJrJbshyM1gwFKaoN9GXx ENcEC1SuwhETIx7B/3FMMs0= X-Google-Smtp-Source: AMsMyM7n1UP/RLYkvvzaXONqfJOhwGmn5jFFdIte8mekieyUEJrvaz37EGv1ZcCTfQoPD7psqTxRaA== X-Received: by 2002:a63:1145:0:b0:46a:e00c:579c with SMTP id 5-20020a631145000000b0046ae00c579cmr18422209pgr.279.1667328417886; Tue, 01 Nov 2022 11:46:57 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id g3-20020a17090a290300b0020d9df9610bsm6314418pjd.19.2022.11.01.11.46.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Nov 2022 11:46:57 -0700 (PDT) Message-ID: Date: Tue, 1 Nov 2022 12:46:56 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost complexity. Content-Language: en-US To: Richard Biener , Dimitrije Milosevic Cc: "gcc-patches@gcc.gnu.org" , Djordje Todorovic References: <20221021135203.626255-1-dimitrije.milosevic@syrmia.com> <20221021135203.626255-2-dimitrije.milosevic@syrmia.com> <3c50de1f-c00b-9f8a-a604-a71bc546f1c2@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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 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