From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77835 invoked by alias); 3 Jul 2018 16:46:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 77826 invoked by uid 89); 3 Jul 2018 16:46:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=throughout, pervasive, H*i:sk:a3367fe, H*f:sk:a3367fe X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Jul 2018 16:46:44 +0000 Received: by mail-wm0-f48.google.com with SMTP id l15-v6so10906583wmc.1 for ; Tue, 03 Jul 2018 09:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=tGI4oB5ASrGc0YKtsCz+antvZDKTtTC4aQz3+LMKivY=; b=P0OnSG64SUB2JS0Fok9rc8/t/3kZqpJ5LnG/XQtJQP1FmHDgyg0+pekJUPuSmEL6dz KqyymOWd+2t94hW9lojiut6aCufAnoIh69C1RHNDP6AGXNwtq2J1oE1NxW6fG3rbocZ7 ujP2Gi6fGacrq8Pmi1qyjySX7bLWR4WTq0E+63rYXgB5O8LFuocBiW518k+Le84F0wYq q1GSqc+0J+7prB6fiIy0oSiWFSOlju6PFSG82OCWGKs89+1bUs+0GxxUIrCw9XdNAlnZ nDDxlQFJvXIKzmaWcZLtOFOs9KT0Yiujkde3NYL/F8bp/c5prFV3ji/ENsR2RdBNANYJ BUdw== Return-Path: Received: from [192.168.178.32] (p2E530C99.dip0.t-ipconnect.de. [46.83.12.153]) by smtp.gmail.com with ESMTPSA id h18-v6sm2322033wrq.36.2018.07.03.09.46.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 09:46:41 -0700 (PDT) Date: Tue, 03 Jul 2018 16:46:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: References: <5b1a8e4b-c0c5-69f7-1800-605e0b844acb@oracle.com> <226ee5ff-ac66-e8a4-7a67-a07a92eaebbb@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Understanding tree_swap_operands_p wrt SSA name versions To: Michael Ploujnikov ,Jeff Law CC: GCC Development From: Richard Biener Message-ID: <165C3FA6-E1CC-454D-8A2A-9DA9348301D8@gmail.com> X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00037.txt.bz2 On July 3, 2018 4:56:57 PM GMT+02:00, Michael Ploujnikov wrote: >On 2018-06-20 04:23 AM, Richard Biener wrote: >> On Wed, Jun 20, 2018 at 7:31 AM Jeff Law wrote: >>> >>> On 06/19/2018 12:30 PM, Michael Ploujnikov wrote: >>>> Hi everyone, >>>> >>>> (I hope this is the right place to ask, if not my apologies; please >>>> point me in the right direction) >>>> >>>> I'm trying to get a better understanding of the following part in >>>> tree_swap_operands_p(): >>>> >>>> /* It is preferable to swap two SSA_NAME to ensure a canonical >form >>>> for commutative and comparison operators. Ensuring a >canonical >>>> form allows the optimizers to find additional redundancies >without >>>> having to explicitly check for both orderings. */ >>>> if (TREE_CODE (arg0) =3D=3D SSA_NAME >>>> && TREE_CODE (arg1) =3D=3D SSA_NAME >>>> && SSA_NAME_VERSION (arg0) > SSA_NAME_VERSION (arg1)) >>>> return 1; >>>> >>>> My questions in no particular order: It looks like this was added >in >>>> 2004. I couldn't find any info other than what's in the >corresponding >>>> commit (cc0bdf913) so I'm wondering if the canonical form/order >still >>>> relevant/needed today? Does the ordering have to be done based on >the >>>> name versions specifically? Or can it be based on something more >>>> intrinsic to the input source code rather than a GCC internal >value, eg: >>>> would alphabetic sort order of the variable names be a reasonable >>>> replacement? >>> Canonicalization is still important and useful. >>=20 >> Indeed. >>=20 >>> However, canonicalizing on SSA_NAMEs is problematical due to the way >we >>> recycle nodes and re-pack them. >>=20 >> In the past we made sure to not disrupt order - hopefully that didn't >change >> so the re-packing shoudln't invaidate previous canonicalization: >>=20 >> static void >> release_free_names_and_compact_live_names (function *fun) >> { >> ... >> /* And compact the SSA number space. We make sure to not change >the >> relative order of SSA versions. */ >> for (i =3D 1, j =3D 1; i < fun->gimple_df->ssa_names->length (); ++i) >> { >>=20 >>=20 >>> I think defining additional rules for canonicalization prior to >using >>> SSA_NAME_VERSION as the fallback would be looked upon favorably. >>=20 >> I don't see a good reason to do that, it will be harder to spot >canonicalization >> issues and it will take extra compile-time. >>=20 >>> Note however, that many of the _DECL nodes referenced by SSA_NAMEs >are >>> temporaries generated by the compiler and do not correspond to any >>> declared/defined object in the original source. So you'll still >need >>> the SSA_NAME_VERSION (or something as stable or better) >canonicalization >>> to handle those cases. >>=20 >> And not all SSA_NAMEs have underlying _DECL nodes (or IDENTIFIER_NODE >names). >>=20 >> Richard. >>=20 >>> Jeff > >After a bit more digging I found that insert_phi_nodes inserts PHIs in >the order of UIDs, which indirectly affects the order of vars in >old_ssa_names, which in turn affects the order in which >make_ssa_name_fn >is called to pick SSA versions from FREE_SSANAMES so in the end >ordering by SSA_NAME_VERSION's is more or less equivalent to ordering >by >UIDs. I'm trying to figure out if there's a way to avoid depending on >UIDs being ordered in a certain way. So if tree_swap_operands_p stays >the same I'm wondering if there's some other info available at the >point >of insert_phi_nodes that would be a good replacement for UID. From my >very limited experience with a very small source input, and if I >understand things correctly, all of the var_infos have a var which is >DECL_P and thus should have an IDENTIFIER_NODE. Is that true in the >general case? I don't fully understand what are all the things that >insert_phi_nodes iterates over. Why do you want to remove the dependence on UID ordering? It's pervasive th= roughout the whole compilation...=20 Richard.=20 >- Michael