public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug testsuite/52563] New: FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1
@ 2012-03-12 13:57 izamyatin at gmail dot com
2012-03-12 14:01 ` [Bug testsuite/52563] " dominiq at lps dot ens.fr
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: izamyatin at gmail dot com @ 2012-03-12 13:57 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1
2012-03-12 13:57 [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
@ 2012-03-12 14:01 ` dominiq at lps dot ens.fr
2012-03-12 14:20 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-03-12 14:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1
2012-03-12 13:57 [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
2012-03-12 14:01 ` [Bug testsuite/52563] " dominiq at lps dot ens.fr
@ 2012-03-12 14:20 ` rguenth at gcc dot gnu.org
2012-03-13 8:11 ` jiangning.liu at arm dot com
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-03-12 14:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1
2012-03-12 13:57 [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
2012-03-12 14:01 ` [Bug testsuite/52563] " dominiq at lps dot ens.fr
2012-03-12 14:20 ` rguenth at gcc dot gnu.org
@ 2012-03-13 8:11 ` jiangning.liu at arm dot com
2012-03-19 9:37 ` liujiangning at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jiangning.liu at arm dot com @ 2012-03-13 8:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1
2012-03-12 13:57 [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
` (2 preceding siblings ...)
2012-03-13 8:11 ` jiangning.liu at arm dot com
@ 2012-03-19 9:37 ` liujiangning at gcc dot gnu.org
2012-03-19 9:58 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: liujiangning at gcc dot gnu.org @ 2012-03-19 9:37 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1
2012-03-12 13:57 [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
` (3 preceding siblings ...)
2012-03-19 9:37 ` liujiangning at gcc dot gnu.org
@ 2012-03-19 9:58 ` rguenth at gcc dot gnu.org
2012-03-20 6:08 ` liujiangning at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-03-19 9:58 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1
2012-03-12 13:57 [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
` (4 preceding siblings ...)
2012-03-19 9:58 ` rguenth at gcc dot gnu.org
@ 2012-03-20 6:08 ` liujiangning at gcc dot gnu.org
2012-03-20 10:04 ` rguenther at suse dot de
2012-03-22 9:29 ` liujiangning at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: liujiangning at gcc dot gnu.org @ 2012-03-20 6:08 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1
2012-03-12 13:57 [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
` (5 preceding siblings ...)
2012-03-20 6:08 ` liujiangning at gcc dot gnu.org
@ 2012-03-20 10:04 ` rguenther at suse dot de
2012-03-22 9:29 ` liujiangning at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: rguenther at suse dot de @ 2012-03-20 10:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1
2012-03-12 13:57 [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
` (6 preceding siblings ...)
2012-03-20 10:04 ` rguenther at suse dot de
@ 2012-03-22 9:29 ` liujiangning at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: liujiangning at gcc dot gnu.org @ 2012-03-22 9:29 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-03-22 9:28 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-12 13:57 [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
2012-03-12 14:01 ` [Bug testsuite/52563] " dominiq at lps dot ens.fr
2012-03-12 14:20 ` rguenth at gcc dot gnu.org
2012-03-13 8:11 ` jiangning.liu at arm dot com
2012-03-19 9:37 ` liujiangning at gcc dot gnu.org
2012-03-19 9:58 ` rguenth at gcc dot gnu.org
2012-03-20 6:08 ` liujiangning at gcc dot gnu.org
2012-03-20 10:04 ` rguenther at suse dot de
2012-03-22 9:29 ` liujiangning at gcc dot gnu.org
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).