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 BB60C385841A for ; Sat, 13 Nov 2021 00:51:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BB60C385841A Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-103-MlJOWQBzMbWuvt1NS9EcSw-1; Fri, 12 Nov 2021 19:51:49 -0500 X-MC-Unique: MlJOWQBzMbWuvt1NS9EcSw-1 Received: by mail-qt1-f198.google.com with SMTP id o12-20020a05622a008c00b002aff5552c89so7965767qtw.23 for ; Fri, 12 Nov 2021 16:51:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=bfu/3qrXQe3nBkVPgIJoc5qib5tbrOeyGuBGEE4Zmt0=; b=ITToVsWJfsIM33PLSaZwnbO9Am5hAvk6lnQAg1264TrkWHt4NWTdzhMNgiwI1gNh9a YPJUoF3bwVF9GqJ/sTPObHfwCyPwnBz/YR9A87D7UAzRuShHv2Ju2lv7X+iUNAhDvqE7 a4QZjyaN01Mi/EjVvsRZZ6dv41oPCWYSHVI/NktKFYguwr3NKLw7frw8ZYOqXAdlJdoM KQ9u5dha4m3RLJF39lW2iZosb4DZmFlWGfRiNLYKxS2WrGdmjcjJDOcSOBulj+OLltDs GeJBzCoJsbG3XY6mBT1RbCNzetOCArX8+eNL3U/VHimHdNLf7o7PolYkMyguLwCKl54a 0Wvg== X-Gm-Message-State: AOAM530cqifBnrnX0nmWN4Oh1pCENjZLYI4Rgn+fM5LfO56FzgttUig7 0Kbn/PaZk/ys+VNny95xu4cfkyz8tRhE1HM7xFdAvHw/zcRBtgbtPMMueu11amNolmM5M+EJpfm n5ZyO+vsCoYZsdwU06A== X-Received: by 2002:a05:622a:118f:: with SMTP id m15mr20683994qtk.81.1636764708710; Fri, 12 Nov 2021 16:51:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJy2W3RenRea93T8eMRwNwxoYxiMEiB+FSUgWRxH/Fw+twc3qGc+kCVSwEmslWXx7EZkzGlVgg== X-Received: by 2002:a05:622a:118f:: with SMTP id m15mr20683975qtk.81.1636764708484; Fri, 12 Nov 2021 16:51:48 -0800 (PST) Received: from [192.168.0.102] ([104.219.122.240]) by smtp.gmail.com with ESMTPSA id w9sm3732087qkp.12.2021.11.12.16.51.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Nov 2021 16:51:48 -0800 (PST) Message-ID: <92701e4b-0f9f-bdcf-63cb-9c57237b85ac@redhat.com> Date: Fri, 12 Nov 2021 19:51:46 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [COMMITTED] path solver: Solve PHI imports first for ranges. To: Richard Biener , Aldy Hernandez , Aldy Hernandez via Gcc-patches References: <20211112194625.1021072-1-aldyh@redhat.com> From: Andrew MacLeod In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-CA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-14.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2021 00:51:54 -0000 On 11/12/21 14:50, Richard Biener via Gcc-patches wrote: > On November 12, 2021 8:46:25 PM GMT+01:00, Aldy Hernandez via Gcc-patches wrote: >> PHIs must be resolved first while solving ranges in a block, >> regardless of where they appear in the import bitmap. We went through >> a similar exercise for the relational code, but missed these. > Must not all stmts be resolved in program order (for optimality at least)? Generally,Imports are live on entry values to a block, so their order is not particularly important.. they are all simultaneous. PHIs are also considered imports for data flow purposes, but they happen before the first stmt, all simultaneously... they need to be distinguished because phi arguments can refer to other phi defs which may be in this block live around a back edge, and we need to be sure we get the right version. we should look closer to be sure this isn't an accidental fix that leaves the root problem .   we need to be sure *all* the PHI arguments are resolved from outside this block. whats the testcase? > >> Tested on x86-64 & ppc64le Linux. >> >> gcc/ChangeLog: >> >> PR tree-optimization/103202 >> * gimple-range-path.cc >> (path_range_query::compute_ranges_in_block): Solve PHI imports first. >> --- >> gcc/gimple-range-path.cc | 15 +++++++++++++-- >> 1 file changed, 13 insertions(+), 2 deletions(-) >> >> diff --git a/gcc/gimple-range-path.cc b/gcc/gimple-range-path.cc >> index b9aceaf2565..71b290434cb 100644 >> --- a/gcc/gimple-range-path.cc >> +++ b/gcc/gimple-range-path.cc >> @@ -365,12 +365,23 @@ path_range_query::compute_ranges_in_block (basic_block bb) >> clear_cache (name); >> } >> >> - // Solve imports defined in this block. >> + // Solve imports defined in this block, starting with the PHIs... >> + for (gphi_iterator iter = gsi_start_phis (bb); !gsi_end_p (iter); >> + gsi_next (&iter)) >> + { >> + gphi *phi = iter.phi (); >> + tree name = gimple_phi_result (phi); >> + >> + if (import_p (name) && range_defined_in_block (r, name, bb)) >> + set_cache (r, name); >> + } >> + // ...and then the rest of the imports. >> EXECUTE_IF_SET_IN_BITMAP (m_imports, 0, i, bi) >> { >> tree name = ssa_name (i); >> >> - if (range_defined_in_block (r, name, bb)) >> + if (gimple_code (SSA_NAME_DEF_STMT (name)) != GIMPLE_PHI >> + && range_defined_in_block (r, name, bb)) >> set_cache (r, name); >> } >>