From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 535E93858D20 for ; Tue, 8 Aug 2023 16:49:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 535E93858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1691513354; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wLL2Pykas2ImdLK92a/F9KXK0kouaGHiIzRSQ1dwp1Y=; b=JREKPV9n3ps11o7cFDwRoVYUK6rQaMZrYVRlQcXMOzFVf4q5rsYGrk7wFMr1R+60dahB5P sopH78Qos74jqrO1bdjX3++AQ0nU95pJHqanU6BmKr6qV8Tp+IFxvmkrsOsLv1YNBjaPle JfGE70+DNWRbTCxCnj7nYSdReQPt4LM= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-505-i2dZU259OL6k7Yv8nmhpMw-1; Tue, 08 Aug 2023 12:49:13 -0400 X-MC-Unique: i2dZU259OL6k7Yv8nmhpMw-1 Received: by mail-qt1-f199.google.com with SMTP id d75a77b69052e-403affb3404so296601cf.1 for ; Tue, 08 Aug 2023 09:49:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691513352; x=1692118152; 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=wLL2Pykas2ImdLK92a/F9KXK0kouaGHiIzRSQ1dwp1Y=; b=HBVYRKWO2Sr+8PVPVmzk9yOAWEFLkvRv6YWrb8R2PN5VgHMw0Zp+Hca1YIl/DDsstL DxTMubm1UbTtkC+UfekHSuNt5cMUXyGKGvZ9gcd1f5mlJuZ3HqiyeDJJVGIqWj3K4Wq1 b1ZwjgY5M8IIU+hD7hLaTBXo3XbF5ZrSFvUSK616qnGHnNsFTDYbvHAJlJNckZRVaMuS jwPpM/SUoCi3Iu+XkqNHEC+vXwogWxmmx1MITa+x51gNp0giKotQyyEGZsPwcwe4KxW4 juQbolBtgNEOMFtrrHCtbOuRSBNMcOFX6xxjb/6VPxg3qxxaVHTJklbBoFYp/gasyOOE 5R5A== X-Gm-Message-State: AOJu0YwEmbbZXijUw4ZCbLGJMfi957y/HnLtEm84ii/iJSA87eSaoLXg v3dHsM70XqHcz6V7d5te1kuuippO1lvJWtTa6kIUhp/SeMQxo7MnyHa7vgyXtptx1S1n139oHo7 foyGjuadYAFPJaBmBRUCP7MPxe328 X-Received: by 2002:a05:6214:40b:b0:636:a374:4ba1 with SMTP id z11-20020a056214040b00b00636a3744ba1mr13131615qvx.14.1691513352646; Tue, 08 Aug 2023 09:49:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFQhhC/57b6s1PZEkObL8dPxgyHOSIit68s7r7NxjKG+t+m12aGiK6wdW+pQUCyBR9BLAr2rw== X-Received: by 2002:a05:6214:40b:b0:636:a374:4ba1 with SMTP id z11-20020a056214040b00b00636a3744ba1mr13131596qvx.14.1691513352372; Tue, 08 Aug 2023 09:49:12 -0700 (PDT) Received: from [192.168.1.88] (192-0-143-139.cpe.teksavvy.com. [192.0.143.139]) by smtp.gmail.com with ESMTPSA id s18-20020a0cdc12000000b0063f78bd525asm3016593qvk.144.2023.08.08.09.49.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Aug 2023 09:49:12 -0700 (PDT) Message-ID: Date: Tue, 8 Aug 2023 12:49:11 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1 To: Richard Biener , Jeff Law Cc: gcc-patches@gcc.gnu.org References: <44c7f5b9-f3d9-4d7a-7090-d483e002ff21@gmail.com> From: Vladimir Makarov In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-13.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_NUMSUBJECT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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 8/7/23 09:18, Richard Biener wrote: > On Wed, 2 Aug 2023, Richard Biener wrote: > >> On Mon, 31 Jul 2023, Jeff Law wrote: >> >>> >>> On 7/31/23 04:54, Richard Biener via Gcc-patches wrote: >>>> On Tue, 25 Jul 2023, Richard Biener wrote: >>>> >>>>> The following applies a micro-optimization to find_hard_regno_for_1, >>>>> re-ordering the check so we can easily jump-thread by using an else. >>>>> This reduces the time spent in this function by 15% for the testcase >>>>> in the PR. >>>>> >>>>> Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK if that >>>>> passes? >>>> Ping. >>>> >>>>> Thanks, >>>>> Richard. >>>>> >>>>> PR rtl-optimization/110587 >>>>> * lra-assigns.cc (find_hard_regno_for_1): Re-order checks. >>>>> --- >>>>> gcc/lra-assigns.cc | 9 +++++---- >>>>> 1 file changed, 5 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/gcc/lra-assigns.cc b/gcc/lra-assigns.cc >>>>> index b8582dcafff..d2ebcfd5056 100644 >>>>> --- a/gcc/lra-assigns.cc >>>>> +++ b/gcc/lra-assigns.cc >>>>> @@ -522,14 +522,15 @@ find_hard_regno_for_1 (int regno, int *cost, int >>>>> @@ try_only_hard_regno, >>>>> r2 != NULL; >>>>> r2 = r2->start_next) >>>>> { >>>>> - if (r2->regno >= lra_constraint_new_regno_start >>>>> + if (live_pseudos_reg_renumber[r2->regno] < 0 >>>>> + && r2->regno >= lra_constraint_new_regno_start >>>>> && lra_reg_info[r2->regno].preferred_hard_regno1 >= 0 >>>>> - && live_pseudos_reg_renumber[r2->regno] < 0 >>>>> && rclass_intersect_p[regno_allocno_class_array[r2->regno]]) >>>>> sparseset_set_bit (conflict_reload_and_inheritance_pseudos, >>>>> r2->regno); >>>>> - if (live_pseudos_reg_renumber[r2->regno] >= 0 >>>>> - && rclass_intersect_p[regno_allocno_class_array[r2->regno]]) >>>>> + else if (live_pseudos_reg_renumber[r2->regno] >= 0 >>>>> + && rclass_intersect_p >>>>> + [regno_allocno_class_array[r2->regno]]) >>>>> sparseset_set_bit (live_range_hard_reg_pseudos, r2->regno); >>> My biggest concern here would be r2->regno < 0 in the new code which could >>> cause an OOB array reference in the first condition of the test. >>> >>> Isn't that the point if the original ordering? Test that r2->regno is >>> reasonable before using it as an array index? >> Note the original code is >> >> if (r2->regno >= lra_constraint_new_regno_start >> ... >> if (live_pseudos_reg_renumber[r2->regno] >= 0 >> ... >> >> so we are going to access live_pseudos_reg_renumber[r2->regno] >> independent on the r2->regno >= lra_constraint_new_regno_start check, >> so I don't think that's the point of the original ordering. Note >> I preserved the ordering with respect to other array accesses, >> the speedup seen is because we now have the >> >> >> if (live_pseudos_reg_renumber[r2->regno] < 0 >> ... >> else if (live_pseudos_reg_renumber[r2->regno] >= 0 >> ... >> >> structure directly exposed which helps the compiler. >> >> I think the check on r2->regno is to decide whether to alter >> conflict_reload_and_inheritance_pseudos or >> live_range_hard_reg_pseudos (so it's also somewhat natural to check >> that first). > So - OK? > Richard, sorry, I overlooked this thread. Yes, it is OK to commit.  In general Jeff has a reasonable concern but in this case r2->regno is always >= 0 and I can not imagine reasons that we will change algorithm in the future in such way when it is not true.