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 B39CC385841B for ; Wed, 19 Jan 2022 18:41:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B39CC385841B 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.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-135-ZvtEpX4sNTW13tLnPmvocg-1; Wed, 19 Jan 2022 13:41:31 -0500 X-MC-Unique: ZvtEpX4sNTW13tLnPmvocg-1 Received: by mail-qt1-f199.google.com with SMTP id f21-20020ac84655000000b002cae5b5722bso1954162qto.10 for ; Wed, 19 Jan 2022 10:41:31 -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:cc:references:from:in-reply-to :content-transfer-encoding; bh=k1Q7mSTrtuTi1s+sfv2DTkuU44i2ZV/XiX9ixJxbj64=; b=DemaXUQ8FNtqprE9vz2hM3J9Hlqt6lhFmVO5rzFeph4VHgPXDav62wxHG7UfIRqJgZ kgxc8n8tbvTC/OM6Pgld3ud49PdMQ+ZsZMO19m5aFFHjd+ufa3ILeK6BPkjIz2IsqcXd ZuJj2jlAf1XgRoq6PGC6lVurwuJlI+tUflXtrno7cmOTQmvgk9GUcVWfipPURhec1rTv cEboTm7Iolm5OtcGm0qufc2s1B3OvCvDqi5y1kaKV399g0kTCMKemHrfyOI5t5rlUJBF fdjIb5bTA0yE4WpyMbamEo3tO5dcz8VCdCq24x75fOFjQzNTYxYeO1Ulu1KWskJdQ3qD E3pA== X-Gm-Message-State: AOAM5326isjpGkHrp2ujbWjMHdi9QSojNp895hR6IixLGlRkn9ilt5R2 4JwKOimmo/7ywZSNOqYpo10GgFG/wNBaIuAskzVjq6QHPZa4/36l9ZaKi5UtF3geUI9poSsM6YU 4Y9u5wHMqfFFRx+6dRg== X-Received: by 2002:a05:6214:230f:: with SMTP id gc15mr28621710qvb.98.1642617691361; Wed, 19 Jan 2022 10:41:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJxk0G3aORXlI99ioiUehmndctZ0XVgTzVwziBHAiYAy5+5O9OEbvaNR/IbTXPVYJhYWf/qWBQ== X-Received: by 2002:a05:6214:230f:: with SMTP id gc15mr28621694qvb.98.1642617691138; Wed, 19 Jan 2022 10:41:31 -0800 (PST) Received: from ?IPV6:2607:fea8:a262:5f00:e36d:32da:80f:d4e1? ([2607:fea8:a262:5f00:e36d:32da:80f:d4e1]) by smtp.gmail.com with ESMTPSA id g74sm294549qke.48.2022.01.19.10.41.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Jan 2022 10:41:30 -0800 (PST) Message-ID: Date: Wed, 19 Jan 2022 13:41:29 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: [PATCH] tree-optimization/103721 - Only add equivalencies that are still valid. To: Richard Biener Cc: gcc-patches References: <79a04182-b37f-0074-20f7-7ebf2aef197c@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=-6.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, 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: Wed, 19 Jan 2022 18:41:35 -0000 On 1/19/22 04:33, Richard Biener wrote: > On Wed, Jan 19, 2022 at 2:37 AM Andrew MacLeod via Gcc-patches > wrote: >> >> OK for trunk? > OK. I don't quite understand how what you describe above works, it sounds > a bit odd with respect to the idea that equivalences should be transitive but The transitive check is what prevents us from having to find and update all the equivalence sets when a name needs to be removed.  we can simply create a new equivalence with that name, and all the older equivalences in the dom tree will no longer equate with it and are eliminated by the query.  With the nature of on-demand, its possible for equivalences to get created in unexpected orders, and logging all the equivalences as they are seen and leaving the final determination to query time seems to be the easiest and most accurate way to get results.  I suspect we miss a few relations if we process things in a  random order, but we shouldn't get anything wrong. > I should note that forming equivalences from PHI nodes with backedges > is not possible without being very careful since you will easily end up > equating _1 and _1 from different iterations (and thus with different value). The dominator search version used by ranger won't create equivalences from back edges normally because the back edge doesn't dominate the block.  The only time we could get an equivalence from a back edge would be if all the other arguments to a PHI at the top of the loop were undefined, or the same value as came in on the back edge ie top_5 = PHI  would create an equivalence between top_5 and val_6...   but that's OK because it is just a copy then anyway. or top_5 = PHI This will create an equivalence between top_5 and val_6 in the loop, until we reach the point where val_6 is defined, and then the equivalence will get killed.  its possible that might cause an issue in a single BB loop, If I could reproduce that...  let me experiment.  In which case I'll simply disable equivalences applied to PHIs if its driven by just a back edge. I dont see any other way we can get an equivalence/relation from a back edge with the oracle (other than what the threader does, it has its own oracle extensions for paths) Its on my task list to document the entire oracle mechanism for both equivalences and relations in the next month or two. Andrew