Understanding tree_swap_operands_p wrt SSA name versions

Richard Biener richard.guenther@gmail.com
Wed Jun 20 11:35:00 GMT 2018


On Wed, Jun 20, 2018 at 7:31 AM Jeff Law <law@redhat.com> 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



More information about the Gcc mailing list