[PATCH] Don't create zero based pointer IVs in ivopts (PR tree-optimization/36038)

Luis Machado luisgpm@linux.vnet.ibm.com
Tue Oct 21 15:16:00 GMT 2008


Jakub,

Thanks for the patch. Give me a couple days and i will provide the spec
results on PPC with the patch applied.

Thanks,
Luis

On Tue, 2008-10-21 at 01:06 +0200, Jakub Jelinek wrote:
> Hi!
> 
> The testcase below fails because ivopts chooses a pointer type ivtmp
> { 0B, +, -8 }_1 and then VRP optimizes that out, as it assumes that ivtmp
> must be NULL.  IMHO when adding IV alternative with initial value zero,
> for pointers that IV should use sizetype, not pointer, as the IV is
> necessarily just an offset that will be added to some base pointer.
> 
> The following patch fixes the testcase on powerpc64-linux (the testcase
> after ivopts is very similar, except the ivtmp is in sizetype and doesn't
> need to be casted to an integer type and back to pointer all the time)
> and passes bootstrap/regtest on x86_64-linux.  Could somebody please
> try it with SPEC to see if it doesn't cause performance regressions?
> 
> 2008-10-20  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR tree-optimization/36038
> 	* tree-ssa-loop-ivopts.c (add_old_iv_candidates): For pointer bases
> 	add sizetype IV with initial value zero instead of pointer type.
> 
> 	* gcc.c-torture/compile/pr36038.c: New test.
> 
> --- gcc/tree-ssa-loop-ivopts.c.jj	2008-10-14 10:17:53.000000000 +0200
> +++ gcc/tree-ssa-loop-ivopts.c	2008-10-20 15:33:31.000000000 +0200
> @@ -2228,9 +2228,11 @@ add_old_iv_candidates (struct ivopts_dat
>    add_candidate (data, iv->base, iv->step, true, NULL);
> 
>    /* The same, but with initial value zero.  */
> -  add_candidate (data,
> -		 build_int_cst (TREE_TYPE (iv->base), 0),
> -		 iv->step, true, NULL);
> +  if (POINTER_TYPE_P (TREE_TYPE (iv->base)))
> +    add_candidate (data, size_int (0), iv->step, true, NULL);
> +  else
> +    add_candidate (data, build_int_cst (TREE_TYPE (iv->base), 0),
> +		   iv->step, true, NULL);
> 
>    phi = SSA_NAME_DEF_STMT (iv->ssa_name);
>    if (gimple_code (phi) == GIMPLE_PHI)
> --- gcc/testsuite/gcc.c-torture/compile/pr36038.c.jj	2008-09-22 10:17:15.262001422 +0200
> +++ gcc/testsuite/gcc.c-torture/compile/pr36038.c	2008-10-20 21:40:45.000000000 +0200
> @@ -0,0 +1,43 @@
> +/* PR tree-optimization/36038 */
> +
> +long long list[10];
> +long long expect[10] = { 0, 1, 2, 3, 4, 4, 5, 6, 7, 9 };
> +long long *stack_base;
> +int indices[10];
> +int *markstack_ptr;
> +
> +void
> +doit (void)
> +{
> +  long long *src;
> +  long long *dst;
> +  long long *sp = stack_base + 5;
> +  int diff = 2;
> +  int shift;
> +  int count;
> +
> +  shift = diff - (markstack_ptr[-1] - markstack_ptr[-2]);
> +  count = (sp - stack_base) - markstack_ptr[-1] + 2;
> +  src = sp;
> +  dst = (sp += shift);
> +  while (--count)
> +    *dst-- = *src--;
> +}
> +
> +int
> +main ()
> +{
> +  int i;
> +  for (i = 0; i < 10; i++)
> +    list[i] = i;
> +
> +  markstack_ptr = indices + 9;
> +  markstack_ptr[-1] = 2;
> +  markstack_ptr[-2] = 1;
> +
> +  stack_base = list + 2;
> +  doit ();
> +  if (__builtin_memcmp (expect, list, sizeof (list)))
> +    __builtin_abort ();
> +  return 0;
> +}
> 
> 	Jakub



More information about the Gcc-patches mailing list