public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH][2/2] Fixup dr_analyze_indices, fix PR50067
@ 2011-08-19 13:33 Richard Guenther
  2011-08-19 14:52 ` Richard Guenther
  0 siblings, 1 reply; 3+ messages in thread
From: Richard Guenther @ 2011-08-19 13:33 UTC (permalink / raw)
  To: gcc-patches


This is the fix for the testcase in PR50067.  We strip outermost
(yes, outermost only, which makes it very inefficient) MEM_REFs
which causes the DR base objects in the PR to agree for two
conflicting DRs, but with the issues we have with how we
compose access functions they still get disambiguated.

Bootstrap and regtest pending on x86_64-unknown-linux-gnu.

Richard.

2011-08-19  Richard Guenther  <rguenther@suse.de>

	PR tree-optimization/50067
	* tree-data-ref.c (dr_analyze_indices): Do not strip
	outermost MEM_REF off its ADDR_EXPR operand.

	* gcc.dg/torture/pr50067-3.c: New testcase.

Index: gcc/tree-data-ref.c
===================================================================
*** gcc/tree-data-ref.c	(revision 177895)
--- gcc/tree-data-ref.c	(working copy)
*************** dr_analyze_indices (struct data_referenc
*** 885,895 ****
      TREE_OPERAND (aref, 1)
        = build_int_cst (TREE_TYPE (TREE_OPERAND (aref, 1)), 0);
  
-   if (TREE_CODE (ref) == MEM_REF
-       && TREE_CODE (TREE_OPERAND (ref, 0)) == ADDR_EXPR
-       && integer_zerop (TREE_OPERAND (ref, 1)))
-     ref = TREE_OPERAND (TREE_OPERAND (ref, 0), 0);
- 
    /* For canonicalization purposes we'd like to strip all outermost
       zero-offset component-refs.
       ???  For now simply handle zero-index array-refs.  */
--- 885,890 ----
Index: gcc/testsuite/gcc.dg/torture/pr50067-3.c
===================================================================
*** gcc/testsuite/gcc.dg/torture/pr50067-3.c	(revision 0)
--- gcc/testsuite/gcc.dg/torture/pr50067-3.c	(revision 0)
***************
*** 0 ****
--- 1,20 ----
+ /* { dg-do run } */
+ /* { dg-options "-fpredictive-commoning" } */
+ 
+ extern void abort (void);
+ int a[6] = { 0, 0, 0, 0, 7, 0 };
+ static int *p = &a[4];
+ 
+ int
+ main ()
+ {
+   int i;
+   for (i = 0; i < 4; ++i)
+     {
+       a[i + 1] = a[i + 2] > i;
+       *p &= ~1;
+     }
+   if (a[4] != 0)
+     abort ();
+   return 0;
+ }

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH][2/2] Fixup dr_analyze_indices, fix PR50067
  2011-08-19 14:52 ` Richard Guenther
@ 2011-08-19 14:52   ` Richard Guenther
  0 siblings, 0 replies; 3+ messages in thread
From: Richard Guenther @ 2011-08-19 14:52 UTC (permalink / raw)
  To: gcc-patches; +Cc: ams

On Fri, 19 Aug 2011, Richard Guenther wrote:

> On Fri, 19 Aug 2011, Richard Guenther wrote:
> 
> > 
> > This is the fix for the testcase in PR50067.  We strip outermost
> > (yes, outermost only, which makes it very inefficient) MEM_REFs
> > which causes the DR base objects in the PR to agree for two
> > conflicting DRs, but with the issues we have with how we
> > compose access functions they still get disambiguated.
> > 
> > Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
> 
> Updated patch, which exposes some latent wide-multiply GIMPLE
> type issues at least.  Fixes all known testcases I have.
> 
> We can't really use the MEM_REF (or maybe any?) offset from
> the base object as independent access-function.  Nor can
> we replace the base with scev_not_known - the alias oracle
> will assume funny things about this (a latent issue for sure).
> 
> Bootstrap and regtest running on x86_64-unknown-linux-gnu,
> I'll have to dig into the latent issue exposed first, but that's
> for next week only.

Bah, bootstrap fails very early when building stage1 libgcc:

/abuild/rguenther/obj3/./gcc/xgcc -B/abuild/rguenther/obj3/./gcc/ 
-B/usr/local/x86_64-unknown-linux-gnu/bin/ 
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem 
/usr/local/x86_64-unknown-linux-gnu/include -isystem 
/usr/local/x86_64-unknown-linux-gnu/sys-include    -g -O2 -m32 -O2  -I. 
-I. -I/space/rguenther/src/svn/trunk/gcc 
-I/space/rguenther/src/svn/trunk/gcc/. 
-I/space/rguenther/src/svn/trunk/gcc/../include 
-I/space/rguenther/src/svn/trunk/gcc/../libdecnumber 
-I/space/rguenther/src/svn/trunk/gcc/../libdecnumber/bid -I../libdecnumber 
-I/space/rguenther/src/svn/trunk/gcc/../libgcc -g -O2 -DIN_GCC   -W -Wall 
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes 
-Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT 
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -I. -I. 
-I../../.././gcc -I/space/rguenther/src/svn/trunk/libgcc 
-I/space/rguenther/src/svn/trunk/libgcc/. 
-I/space/rguenther/src/svn/trunk/libgcc/../gcc 
-I/space/rguenther/src/svn/trunk/libgcc/../include 
-I/space/rguenther/src/svn/trunk/libgcc/config/libbid 
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -o bid64_div.o -MT 
bid64_div.o -MD -MP -MF bid64_div.dep -c 
/space/rguenther/src/svn/trunk/libgcc/config/libbid/bid64_div.c
/space/rguenther/src/svn/trunk/libgcc/config/libbid/bid64_div.c: In 
function '__bid64dq_div':
/space/rguenther/src/svn/trunk/libgcc/config/libbid/bid64_div.c:523:51: 
warning: variable 'Ql' set but not used [-Wunused-but-set-variable]
/space/rguenther/src/svn/trunk/libgcc/config/libbid/bid64_div.c: In 
function '__bid64qd_div':
/space/rguenther/src/svn/trunk/libgcc/config/libbid/bid64_div.c:937:51: 
warning: variable 'Ql' set but not used [-Wunused-but-set-variable]
/space/rguenther/src/svn/trunk/libgcc/config/libbid/bid64_div.c: In 
function '__bid64qq_div':
/space/rguenther/src/svn/trunk/libgcc/config/libbid/bid64_div.c:1374:51: 
warning: variable 'Ql' set but not used [-Wunused-but-set-variable]
PD_359 = digit_22 w* 109951163;

/space/rguenther/src/svn/trunk/libgcc/config/libbid/bid64_div.c: In 
function '__bid64_div':
/space/rguenther/src/svn/trunk/libgcc/config/libbid/bid64_div.c:80:1: 
internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

I suppose it's exposed by

2011-08-19  Andrew Stubbs  <ams@codesourcery.com>

       * tree-ssa-math-opts.c (build_and_insert_cast): New function.
        (is_widening_mult_rhs_p): Allow widening by more than one mode.
        Explicitly disallow mis-matched input types.
        (convert_mult_to_widen): Use find_widening_optab_handler, and cast
        input types to fit the new handler.
        (convert_plusminus_to_widen): Likewise.

Andrew - appearantly you broke bootstrap on x86_64.

Richard.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH][2/2] Fixup dr_analyze_indices, fix PR50067
  2011-08-19 13:33 [PATCH][2/2] Fixup dr_analyze_indices, fix PR50067 Richard Guenther
@ 2011-08-19 14:52 ` Richard Guenther
  2011-08-19 14:52   ` Richard Guenther
  0 siblings, 1 reply; 3+ messages in thread
From: Richard Guenther @ 2011-08-19 14:52 UTC (permalink / raw)
  To: gcc-patches

On Fri, 19 Aug 2011, Richard Guenther wrote:

> 
> This is the fix for the testcase in PR50067.  We strip outermost
> (yes, outermost only, which makes it very inefficient) MEM_REFs
> which causes the DR base objects in the PR to agree for two
> conflicting DRs, but with the issues we have with how we
> compose access functions they still get disambiguated.
> 
> Bootstrap and regtest pending on x86_64-unknown-linux-gnu.

Updated patch, which exposes some latent wide-multiply GIMPLE
type issues at least.  Fixes all known testcases I have.

We can't really use the MEM_REF (or maybe any?) offset from
the base object as independent access-function.  Nor can
we replace the base with scev_not_known - the alias oracle
will assume funny things about this (a latent issue for sure).

Bootstrap and regtest running on x86_64-unknown-linux-gnu,
I'll have to dig into the latent issue exposed first, but that's
for next week only.

Eventually all these changes need backporting to 4.6, even if
the individual testcases do not fail there.

Thanks,
Richard.

2011-08-19  Richard Guenther  <rguenther@suse.de>

	PR tree-optimization/50067
	* tree-data-ref.c (dr_analyze_indices): Do not strip
	outermost MEM_REF off its ADDR_EXPR operand.  Do not strip
	offset operand off MEM_REFs.  Do not leak scev_not_known
	into DR_BASE_OBJECT.

	* gcc.dg/torture/pr50067-3.c: New testcase.
	* gcc.dg/torture/pr50067-4.c: Likewise.

Index: gcc/tree-data-ref.c
===================================================================
*** gcc/tree-data-ref.c	(revision 177903)
--- gcc/tree-data-ref.c	(working copy)
*************** dr_analyze_indices (struct data_referenc
*** 868,894 ****
        op = TREE_OPERAND (aref, 0);
        access_fn = analyze_scalar_evolution (loop, op);
        access_fn = instantiate_scev (before_loop, loop, access_fn);
!       base = initial_condition (access_fn);
!       split_constant_offset (base, &base, &off);
!       if (!integer_zerop (TREE_OPERAND (aref, 1)))
  	{
! 	  off = size_binop (PLUS_EXPR, off,
! 			    fold_convert (ssizetype, TREE_OPERAND (aref, 1)));
! 	  TREE_OPERAND (aref, 1)
! 	    = build_int_cst (TREE_TYPE (TREE_OPERAND (aref, 1)), 0);
  	}
-       access_fn = chrec_replace_initial_condition (access_fn,
- 			fold_convert (TREE_TYPE (base), off));
- 
-       TREE_OPERAND (aref, 0) = base;
        VEC_safe_push (tree, heap, access_fns, access_fn);
      }
  
-   if (TREE_CODE (ref) == MEM_REF
-       && TREE_CODE (TREE_OPERAND (ref, 0)) == ADDR_EXPR
-       && integer_zerop (TREE_OPERAND (ref, 1)))
-     ref = TREE_OPERAND (TREE_OPERAND (ref, 0), 0);
- 
    /* For canonicalization purposes we'd like to strip all outermost
       zero-offset component-refs.
       ???  For now simply handle zero-index array-refs.  */
--- 868,884 ----
        op = TREE_OPERAND (aref, 0);
        access_fn = analyze_scalar_evolution (loop, op);
        access_fn = instantiate_scev (before_loop, loop, access_fn);
!       if (!automatically_generated_chrec_p (access_fn))
  	{
! 	  base = initial_condition (access_fn);
! 	  split_constant_offset (base, &base, &off);
! 	  access_fn = chrec_replace_initial_condition
! 	      (access_fn, fold_convert (TREE_TYPE (base), off));
! 	  TREE_OPERAND (aref, 0) = base;
  	}
        VEC_safe_push (tree, heap, access_fns, access_fn);
      }
  
    /* For canonicalization purposes we'd like to strip all outermost
       zero-offset component-refs.
       ???  For now simply handle zero-index array-refs.  */
Index: gcc/testsuite/gcc.dg/torture/pr50067-3.c
===================================================================
*** gcc/testsuite/gcc.dg/torture/pr50067-3.c	(revision 0)
--- gcc/testsuite/gcc.dg/torture/pr50067-3.c	(revision 0)
***************
*** 0 ****
--- 1,20 ----
+ /* { dg-do run } */
+ /* { dg-options "-fpredictive-commoning" } */
+ 
+ extern void abort (void);
+ int a[6] = { 0, 0, 0, 0, 7, 0 };
+ static int *p = &a[4];
+ 
+ int
+ main ()
+ {
+   int i;
+   for (i = 0; i < 4; ++i)
+     {
+       a[i + 1] = a[i + 2] > i;
+       *p &= ~1;
+     }
+   if (a[4] != 0)
+     abort ();
+   return 0;
+ }
Index: gcc/testsuite/gcc.dg/torture/pr50067-4.c
===================================================================
*** gcc/testsuite/gcc.dg/torture/pr50067-4.c	(revision 0)
--- gcc/testsuite/gcc.dg/torture/pr50067-4.c	(revision 0)
***************
*** 0 ****
--- 1,20 ----
+ /* { dg-do run } */
+ 
+ /* Verify we do not get a bogus access function with 0B vs. 1B which
+    disambiguates both accesses and leads to vectorization.  */
+ 
+ extern int memcmp(const void *, const void *, __SIZE_TYPE__);
+ extern void abort (void);
+ short a[33] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 };
+ short b[33] = { 0, };
+ int main()
+ {
+   int i;
+   for (i = 0; i < 64; ++i)
+     {
+       (*((char(*)[])&a[1]))[i] = (*((char(*)[])&a[0]))[i+1];
+     }
+   if (memcmp (&a, &b, sizeof (a)) != 0)
+     abort ();
+   return 0;
+ }

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-08-19 14:41 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-19 13:33 [PATCH][2/2] Fixup dr_analyze_indices, fix PR50067 Richard Guenther
2011-08-19 14:52 ` Richard Guenther
2011-08-19 14:52   ` Richard Guenther

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).