[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