[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.

["amker at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052

--- Comment #16 from amker at gcc dot gnu.org ---
(In reply to amker from comment #14)
> Author: amker
> Date: Wed Mar  2 14:10:56 2016
> New Revision: 233907
> 
> URL: https://gcc.gnu.org/viewcvs?rev=233907&root=gcc&view=rev
> Log:
> 
> 	PR tree-optimization/69052
> 	* loop-invariant.c (canonicalize_address): New function.
> 	(inv_can_prop_to_addr_use): Check validity of address expression
> 	which is canonicalized by above function.
> 
> 	gcc/testsuite/ChangeLog
> 	PR tree-optimization/69052
> 	* gcc.target/i386/pr69052.c: New test.
> 
> 
> Added:
>     trunk/gcc/testsuite/gcc.target/i386/pr69052.c
> Modified:
>     trunk/gcc/ChangeLog
>     trunk/gcc/loop-invariant.c
>     trunk/gcc/testsuite/ChangeLog

Just realized that CONST_INT and CONST_WIDE_INT both have the same precedence. 
The patch I applied could be broken in cases which have both CONST_INT and
CONST_WIDE_INT address parts and the CONST_WIDE_INT one happens to be sorted
after CONST_INT, as below code:

  /* Simplify all constant int summary if possible.  */
  for (i = 0; i < addr_parts.length (); i++)
    if (CONST_INT_P (addr_parts[i]))
      break;

  for (j = i + 1; j < addr_parts.length (); j++)
    {
      gcc_assert (CONST_INT_P (addr_parts[j]));  <-----assertion failure
      addr_parts[i] = simplify_gen_binary (PLUS, mode,
                                           addr_parts[i],
                                           addr_parts[j]);
    }

Although I don't think we can really run into such complicated address
expression, I will work out a patch to compare_address_parts to force CONST_INT
after CONST_WIDE_INT during sorting.