[Bug testsuite/52563] New: FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1

[Bug testsuite/52563] New: FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1

[izamyatin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563

             Bug #: 52563
           Summary: FAIL: gcc.dg/tree-ssa/scev-[3,4].c
                    scan-tree-dump-times optimized "&a" 1
    Classification: Unclassified
           Product: gcc
           Version: tree-ssa
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: izamyatin@gmail.com
                CC: jiangning.liu@arm.com
            Target: x86_64-unknown-linux-gnu


Fails appeared after revision 185129:

2012-03-09 Jiangning Liu <jiangning.liu@arm.com> 

tree-scalar-evolution (interpret_rhs_expr): generate chrec for
array reference and component reference.
(analyze_scalar_evolution_for_address_of): New. 
2012-03-09 Jiangning Liu <jiangning.liu@arm.com> 

gcc.dg/tree-ssa/scev-3.c: New. 
gcc.dg/tree-ssa/scev-4.c: New. 


 Probably some simple misprint in tests - there are 2 "&a" in dumps...

[Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|x86_64-unknown-linux-gnu    |x86_64-*-*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-03-12
     Ever Confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-03-12 14:00:49 UTC ---
Also seen on x86_64-apple-darwin10 with -m64.

[Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-03-12 14:19:58 UTC ---
We now perform store motion for the address computation as expected.  The
question is what the testcase was for (I suppose final-value-replacement
non-optimization) and eventually disable lim on them.

[Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1

[jiangning.liu at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563

--- Comment #3 from Jiangning Liu <jiangning.liu at arm dot com> 2012-03-13 08:11:40 UTC ---
First, I tried gcc 4.4.3 on x86-64, and it works for this test case, so it is
to some extension a GCC regression.

Second, I tried trunk, and I can reproduce the failure for this test case. It
means there are still some other bugs hidden after my scalar evolution
improvement on address of array element.

Third, loop ivopt should be able to find &a is the base object of a selected IV
candidate after the analysis from simple_iv. After loop ivopt, I see the
following dump,

Selected IV set:
candidate 5 (important)
  depends on 1
  var_before i_13
  var_after i_6
  original biv
  type int
  base k_2(D)
  step k_2(D)
candidate 6
  depends on 1
  var_before ivtmp.11_9
  var_after ivtmp.11_1
  incremented before exit test
  type unsigned long
  base (unsigned long) ((int *) &a + (sizetype) k_2(D) * 4)
  step (unsigned long) ((sizetype) k_2(D) * 4)
  base object (void *) &a

So &a is already identified as an IV base object, but somehow only one &a is 
hoisted out of loop, while the other one isn't.

<bb 4>:
  D.1728_15 = (sizetype) k_2(D);
  D.1729_16 = D.1728_15 * 4;
  D.1730_17 = (sizetype) k_2(D);
  D.1731_18 = D.1730_17 * 4;
  D.1732_19 = &a + D.1731_18;
  ivtmp.11_20 = (unsigned long) D.1732_19;

<bb 5>:
  # i_13 = PHI <i_6(7), k_2(D)(4)>
  # ivtmp.11_9 = PHI <ivtmp.11_1(7), ivtmp.11_20(4)>
  a_p.0_4 = (int *) ivtmp.11_9;
  MEM[(int *)&a][i_13] = 100;
  i_6 = i_13 + k_2(D);
  ivtmp.11_1 = ivtmp.11_9 + D.1729_16;
  if (i_6 <= 999)
    goto <bb 7>;
  else
    goto <bb 6>;

This statement,

  MEM[(int *)&a][i_13] = 100;

is expected to be like,

  D.4086_21 = (void *) ivtmp.11_9;
  MEM[base: D.4086_21, offset: 0B] = 100;

after loop ivopt.

[Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1

[liujiangning at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563

Jiangning Liu <liujiangning at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |liujiangning at gcc dot
                   |                            |gnu.org

--- Comment #4 from Jiangning Liu <liujiangning at gcc dot gnu.org> 2012-03-19 04:10:36 UTC ---
Hi,

  /* In general,
     (TYPE) (BASE + STEP * i) = (TYPE) BASE + (TYPE -- sign extend) STEP * i,
     but we must check some assumptions.

     1) If [BASE, +, STEP] wraps, the equation is not valid when precision
        of CT is smaller than the precision of TYPE.  For example, when we
    cast unsigned char [254, +, 1] to unsigned, the values on left side
    are 254, 255, 0, 1, ..., but those on the right side are
    254, 255, 256, 257, ...
     2) In case that we must also preserve the fact that signed ivs do not
        overflow, we must additionally check that the new iv does not wrap.
    For example, unsigned char [125, +, 1] casted to signed char could
    become a wrapping variable with values 125, 126, 127, -128, -127, ...,
    which would confuse optimizers that assume that this does not
    happen.  */
  must_check_src_overflow = TYPE_PRECISION (ct) < TYPE_PRECISION (type);

The code above in function convert_affine_scev set must_check_src_overflow to
true for 32-bit, while set false for 64-bit code.

This means 64-bit mode fails to unfold the address expression for array element
because of the case 1) as listed in comments above.

For the address of array element a[i], "&a + unitsize * i" has different
representation for 32-bit and 64-bit. For 32-bit, it is "(32-bit pointer) +
(32-bit integer)", while for 64-bit, it is "(64-bit pointer) + (32-bit
integer)".

If you try the case scev-5.c as below, you may find the case can pass.

/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-optimized" } */

int *a_p;
int a[1000];

f(int k)
{
        long long i;

        for (i=k; i<1000; i+=k) {
                a_p = &a[i];
                *a_p = 100;
        }
}

/* { dg-final { scan-tree-dump-times "&a" 1 "optimized" } } */
/* { dg-final { cleanup-tree-dump "optimized" } } */

Any idea to fix this problem?

Thanks,
-Jiangning

[Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-03-19 09:55:15 UTC ---
This statement,

  MEM[(int *)&a][i_13] = 100;

is expected to be like,

  D.4086_21 = (void *) ivtmp.11_9;
  MEM[base: D.4086_21, offset: 0B] = 100;

after loop ivopt.

If the mem is not changed then we failed to analyze it.

(In reply to comment #4)
> Hi,
> 
>   /* In general,
>      (TYPE) (BASE + STEP * i) = (TYPE) BASE + (TYPE -- sign extend) STEP * i,
>      but we must check some assumptions.
> 
>      1) If [BASE, +, STEP] wraps, the equation is not valid when precision
>         of CT is smaller than the precision of TYPE.  For example, when we
>     cast unsigned char [254, +, 1] to unsigned, the values on left side
>     are 254, 255, 0, 1, ..., but those on the right side are
>     254, 255, 256, 257, ...
>      2) In case that we must also preserve the fact that signed ivs do not
>         overflow, we must additionally check that the new iv does not wrap.
>     For example, unsigned char [125, +, 1] casted to signed char could
>     become a wrapping variable with values 125, 126, 127, -128, -127, ...,
>     which would confuse optimizers that assume that this does not
>     happen.  */
>   must_check_src_overflow = TYPE_PRECISION (ct) < TYPE_PRECISION (type);
> 
> The code above in function convert_affine_scev set must_check_src_overflow to
> true for 32-bit, while set false for 64-bit code.
> 
> This means 64-bit mode fails to unfold the address expression for array element
> because of the case 1) as listed in comments above.
> 
> For the address of array element a[i], "&a + unitsize * i" has different
> representation for 32-bit and 64-bit. For 32-bit, it is "(32-bit pointer) +
> (32-bit integer)", while for 64-bit, it is "(64-bit pointer) + (32-bit
> integer)".

Of course.  'i' is 'int', thus 32bit on 64bit, so it is
&a + 4 * (sizetype) i

this is the usual issue that we lose overflow knowledge with the current
POINTER_PLUS_EXPR representation (forced unsigned offset, forced sizetype
precision offset).

> If you try the case scev-5.c as below, you may find the case can pass.
> 
> /* { dg-do compile } */
> /* { dg-options "-O2 -fdump-tree-optimized" } */
> 
> int *a_p;
> int a[1000];
> 
> f(int k)
> {
>         long long i;
> 
>         for (i=k; i<1000; i+=k) {
>                 a_p = &a[i];
>                 *a_p = 100;
>         }
> }
> 
> /* { dg-final { scan-tree-dump-times "&a" 1 "optimized" } } */
> /* { dg-final { cleanup-tree-dump "optimized" } } */
> 
> Any idea to fix this problem?

We cannot fix it without relaxing the POINTER_PLUS_EXPR constraints.
I was working on that, but as usual the TYPE_IS_SIZETYPE removal
has priority.

Please consider fixing/XFAILing the testcases as they still FAIL and you
are responsible for this.  You can open a new enhancement PR covering
this.

> Thanks,
> -Jiangning

[Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1

[liujiangning at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563

--- Comment #6 from Jiangning Liu <liujiangning at gcc dot gnu.org> 2012-03-20 02:32:12 UTC ---
> We cannot fix it without relaxing the POINTER_PLUS_EXPR constraints.
> I was working on that, but as usual the TYPE_IS_SIZETYPE removal
> has priority.

Do you mean you are also working on removing TYPE_IS_SIZETYPE?

> 
> Please consider fixing/XFAILing the testcases as they still FAIL and you
> are responsible for this.  You can open a new enhancement PR covering
> this.
> 

I think 64-bit mode should also have this optimization enabled. XFAIL implies
the missing of this optimization is a correct behavior. But I think this is not
what I expected. So I don't think we should add XFAIL for this case. Instead I
want to add a new test case scev-5.c to cover 64-bit testing.

Thanks,
-Jiangning

[Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> 2012-03-20 09:51:00 UTC ---
On Tue, 20 Mar 2012, liujiangning at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563
> 
> --- Comment #6 from Jiangning Liu <liujiangning at gcc dot gnu.org> 2012-03-20 02:32:12 UTC ---
> > We cannot fix it without relaxing the POINTER_PLUS_EXPR constraints.
> > I was working on that, but as usual the TYPE_IS_SIZETYPE removal
> > has priority.
> 
> Do you mean you are also working on removing TYPE_IS_SIZETYPE?

Yes.

> > 
> > Please consider fixing/XFAILing the testcases as they still FAIL and you
> > are responsible for this.  You can open a new enhancement PR covering
> > this.
> > 
> 
> I think 64-bit mode should also have this optimization enabled. XFAIL implies
> the missing of this optimization is a correct behavior. But I think this is not
> what I expected. So I don't think we should add XFAIL for this case. Instead I
> want to add a new test case scev-5.c to cover 64-bit testing.

XFAIL says it's a known failure.

Richard.

[Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1

[liujiangning at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563

--- Comment #8 from Jiangning Liu <liujiangning at gcc dot gnu.org> 2012-03-22 09:17:51 UTC ---
Author: liujiangning
Date: Thu Mar 22 09:17:45 2012
New Revision: 185678

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185678
Log:
2012-03-22  Jiangning Liu  <jiangning.liu@arm.com>                              

    PR tree-optimization/52563
    * gcc.dg/tree-ssa/scev-3.c: XFAIL on lp64.
    * gcc.dg/tree-ssa/scev-4.c: XFAIL on lp64.
    * gcc.dg/tree-ssa/scev-5.c: New.


Added:
    trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c
Modified:
    trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c
    trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c