From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20896 invoked by alias); 20 Jun 2018 08:24:03 -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 121417 invoked by uid 89); 20 Jun 2018 08:23:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=ssa_names, recycle, problematical, ploujnikov X-HELO: mail-lf0-f43.google.com Received: from mail-lf0-f43.google.com (HELO mail-lf0-f43.google.com) (209.85.215.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Jun 2018 08:23:37 +0000 Received: by mail-lf0-f43.google.com with SMTP id x13-v6so3585915lff.10 for ; Wed, 20 Jun 2018 01:23:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5tNl0MCjFmTSANQJE/7zUtKiQ3SHSu0PcpqsarJEg2s=; b=Er7pDfTl9XK2A3/Y0S2pikfImZEdF6e2dk1yrdYAUxD+CXTZZBeOFKQNBqovLQHX+X aIYogk3cTzu++E6+l9CAqWLji5PmnBCZr7oCUKgYJLrnADlycZc351ZROiyi5NxnkTq/ zLqMRVcSHfqqMbCV0xUzX6l9PknU7YfWMmbQjyno4Hpr5Vl+hSJgv0v+Q7KLKbEDsyme mHoLqMwA3KjOIYYnbICOA2tBu7W4psz7iKdxUcA3miUEprAnoWFoYd9V/poP406lNpCT IjM5Or/w2hJKKSMysdKcQ/03DcjHT2JC7X9kv4gV1M0r/KdWZ2Ajm71D14oSOuAIqgCV t2cw== X-Gm-Message-State: APt69E3WEeKTIkJR1ic9fL/M4dB9XWDbpea9eif0z+wQQNNo8/s40yAC ukWuAi6PeITRzB0TCyqeWIwomfb0q19y6fzjKhE= X-Google-Smtp-Source: ADUXVKL7iTHzBigOD60sNSp80EX4v1ZqbxCvu9mz12KQysqV3LwCFAEecMyMqh/lQQNuwonVKY2xLcugy8QYfUuXpu0= X-Received: by 2002:a19:9486:: with SMTP id o6-v6mr4595945lfk.38.1529483014362; Wed, 20 Jun 2018 01:23:34 -0700 (PDT) MIME-Version: 1.0 References: <5b1a8e4b-c0c5-69f7-1800-605e0b844acb@oracle.com> <226ee5ff-ac66-e8a4-7a67-a07a92eaebbb@redhat.com> In-Reply-To: <226ee5ff-ac66-e8a4-7a67-a07a92eaebbb@redhat.com> From: Richard Biener Date: Wed, 20 Jun 2018 11:35:00 -0000 Message-ID: Subject: Re: Understanding tree_swap_operands_p wrt SSA name versions To: Jeff Law Cc: michael.ploujnikov@oracle.com, GCC Development Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00212.txt.bz2 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) == SSA_NAME > > && TREE_CODE (arg1) == 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. Indeed. > However, canonicalizing on SSA_NAMEs is problematical due to the way we > recycle nodes and re-pack them. In the past we made sure to not disrupt order - hopefully that didn't change so the re-packing shoudln't invaidate previous canonicalization: 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 = 1, j = 1; i < fun->gimple_df->ssa_names->length (); ++i) { > I think defining additional rules for canonicalization prior to using > SSA_NAME_VERSION as the fallback would be looked upon favorably. 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. > 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. And not all SSA_NAMEs have underlying _DECL nodes (or IDENTIFIER_NODE names). Richard. > Jeff