public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
@ 2013-12-16 1:39 su at cs dot ucdavis.edu
2013-12-16 17:19 ` [Bug tree-optimization/59519] " su at cs dot ucdavis.edu
` (13 more replies)
0 siblings, 14 replies; 15+ messages in thread
From: su at cs dot ucdavis.edu @ 2013-12-16 1:39 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 9716 bytes --]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
Bug ID: 59519
Summary: ICE on valid code at -O3 on x86_64-linux-gnu in
slpeel_update_phi_nodes_for_guard1, at
tree-vect-loop-manip.c:486
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++,lto --enable-checking=release --disable-werror
--enable-multilib
Thread model: posix
gcc version 4.9.0 20131215 (experimental) [trunk revision 206004] (GCC)
$
$ gcc-trunk -O2 -c small.c
$ gcc-4.8 -O3 -c small.c
$
$ gcc-trunk -O3 -c small.c
small.c: In function âfooâ:
small.c:9:1: internal compiler error: in slpeel_update_phi_nodes_for_guard1, at
tree-vect-loop-manip.c:486
foo ()
^
0xa01706 slpeel_update_phi_nodes_for_guard1
../../gcc-trunk/gcc/tree-vect-loop-manip.c:486
0xa01706 slpeel_tree_peel_loop_to_edge
../../gcc-trunk/gcc/tree-vect-loop-manip.c:1411
0xa02281 vect_do_peeling_for_alignment(_loop_vec_info*, tree_node*, unsigned
int, bool)
../../gcc-trunk/gcc/tree-vect-loop-manip.c:2009
0x9f624f vect_transform_loop(_loop_vec_info*)
../../gcc-trunk/gcc/tree-vect-loop.c:5797
0xa0dacf vectorize_loops()
../../gcc-trunk/gcc/tree-vectorizer.c:473
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
---------------------------------
struct
{
int f0;
} d;
int a[8] = {0}, b, c, e;
void
foo ()
{
for (; e < 1; e++)
for (b = 0; b < 7; b++)
{
c |= (a[b+1] != 0);
if (d.f0)
break;
}
}
>From gcc-bugs-return-437678-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 16 02:23:05 2013
Return-Path: <gcc-bugs-return-437678-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30404 invoked by alias); 16 Dec 2013 02:23:04 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 30379 invoked by uid 48); 16 Dec 2013 02:23:00 -0000
From: "su at cs dot ucdavis.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59520] New: a possible inconsistency in error diagnostics with "-pedantic -stdÉ9"
Date: Mon, 16 Dec 2013 02:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: su at cs dot ucdavis.edu
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-59520-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg01333.txt.bz2
Content-length: 2119
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520
Bug ID: 59520
Summary: a possible inconsistency in error diagnostics with
"-pedantic -std=c99"
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
I wonder whether or not the following examples illustrate an unintended
inconsistency with error diagnostics in GCC.
In particular, should the diagnostic message be a warning for error3.c rather
than an error as shown below?
error3.c:1:5: error: zero or negative size array âaâ
int a[] = {};
^
---------------
$ gcc-trunk -pedantic -std=c99 -c error1.c
error1.c:1:12: warning: ISO C forbids empty initializer braces [-Wpedantic]
int a[1] = {};
^
$ clang-trunk -pedantic -std=c99 -c error1.c
error1.c:1:12: warning: use of GNU empty initializer extension
[-Wgnu-empty-initializer]
int a[1] = {};
^
1 warning generated.
$ cat error1.c
int a[1] = {};
$
---------------
$ gcc-trunk -pedantic -std=c99 -c error2.c
error2.c:1:5: warning: array âaâ assumed to have one element [enabled by
default]
int a[];
^
$ clang-trunk -pedantic -std=c99 -c error2.c
error2.c:1:5: warning: tentative array definition assumed to have one element
int a[];
^
1 warning generated.
$ cat error2.c
int a[];
$
---------------
$ gcc-trunk -pedantic -std=c99 -c error3.c
error3.c:1:11: warning: ISO C forbids empty initializer braces [-Wpedantic]
int a[] = {};
^
error3.c:1:5: error: zero or negative size array âaâ
int a[] = {};
^
$ clang-trunk -pedantic -std=c99 -c error3.c
error3.c:1:11: warning: use of GNU empty initializer extension
[-Wgnu-empty-initializer]
int a[] = {};
^
error3.c:1:11: warning: zero size arrays are an extension [-Wzero-length-array]
2 warnings generated.
$ cat error3.c
int a[] = {};
$
>From gcc-bugs-return-437679-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 16 02:27:33 2013
Return-Path: <gcc-bugs-return-437679-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32292 invoked by alias); 16 Dec 2013 02:27:33 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 32273 invoked by uid 48); 16 Dec 2013 02:27:29 -0000
From: "drepper.fsp at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/59521] New: __builtin_expect not effective in switch
Date: Mon, 16 Dec 2013 02:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: drepper.fsp at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-59521-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg01334.txt.bz2
Content-length: 1857
http://gcc.gnu.org/bugzilla/show_bug.cgi?idY521
Bug ID: 59521
Summary: __builtin_expect not effective in switch
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp at gmail dot com
When used in switch, __builtin_expect should reorder the comparisons
appropriately. Take this code:
#include <stdio.h>
void
f(int ch) {
switch (__builtin_expect(ch, 333)) {
case 3: puts("a"); break;
case 42: puts("e"); break;
case 333: puts("i"); break;
}
}
Current mainline (and also prior versions, I tested 4.8.2) produce with -O3
code like this:
0000000000000000 <f>:
0: 83 ff 2a cmp $0x2a,%edi
3: 74 33 je 38 <f+0x38>
5: 81 ff 4d 01 00 00 cmp $0x14d,%edi
b: 74 1b je 28 <f+0x28>
d: 83 ff 03 cmp $0x3,%edi
10: 74 06 je 18 <f+0x18>
12: c3 retq
13: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
18: bf 00 00 00 00 mov $0x0,%edi
1d: e9 00 00 00 00 jmpq 22 <f+0x22>
22: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
28: bf 00 00 00 00 mov $0x0,%edi
2d: e9 00 00 00 00 jmpq 32 <f+0x32>
32: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
38: bf 00 00 00 00 mov $0x0,%edi
3d: e9 00 00 00 00 jmpq 42 <f+0x42>
Instead the test for 333/$0x14d should have been moved to the front.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/59519] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
2013-12-16 1:39 [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486 su at cs dot ucdavis.edu
@ 2013-12-16 17:19 ` su at cs dot ucdavis.edu
2013-12-17 19:21 ` [Bug tree-optimization/59519] [4.9 Regression] " mpolacek at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: su at cs dot ucdavis.edu @ 2013-12-16 17:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #1 from Zhendong Su <su at cs dot ucdavis.edu> ---
Below is simpler testcase that triggers the same ICE:
------------------------------------
int a, b, c, d;
void
foo ()
{
for (; d; d++)
for (b = 0; b < 14; b++)
{
c |= 1;
if (a)
break;
}
}
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
2013-12-16 1:39 [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486 su at cs dot ucdavis.edu
2013-12-16 17:19 ` [Bug tree-optimization/59519] " su at cs dot ucdavis.edu
@ 2013-12-17 19:21 ` mpolacek at gcc dot gnu.org
2013-12-19 11:46 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2013-12-17 19:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-12-17
CC| |mpolacek at gcc dot gnu.org
Target Milestone|--- |4.9.0
Summary|ICE on valid code at -O3 on |[4.9 Regression] ICE on
|x86_64-linux-gnu in |valid code at -O3 on
|slpeel_update_phi_nodes_for |x86_64-linux-gnu in
|_guard1, at |slpeel_update_phi_nodes_for
|tree-vect-loop-manip.c:486 |_guard1, at
| |tree-vect-loop-manip.c:486
Ever confirmed|0 |1
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
2013-12-16 1:39 [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486 su at cs dot ucdavis.edu
2013-12-16 17:19 ` [Bug tree-optimization/59519] " su at cs dot ucdavis.edu
2013-12-17 19:21 ` [Bug tree-optimization/59519] [4.9 Regression] " mpolacek at gcc dot gnu.org
@ 2013-12-19 11:46 ` jakub at gcc dot gnu.org
2013-12-19 12:02 ` amker.cheng at gmail dot com
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-12-19 11:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amker at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r205959.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
2013-12-16 1:39 [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486 su at cs dot ucdavis.edu
` (2 preceding siblings ...)
2013-12-19 11:46 ` jakub at gcc dot gnu.org
@ 2013-12-19 12:02 ` amker.cheng at gmail dot com
2013-12-19 14:45 ` amker.cheng at gmail dot com
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: amker.cheng at gmail dot com @ 2013-12-19 12:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
bin.cheng <amker.cheng at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amker.cheng at gmail dot com
--- Comment #3 from bin.cheng <amker.cheng at gmail dot com> ---
I will look into it.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
2013-12-16 1:39 [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486 su at cs dot ucdavis.edu
` (3 preceding siblings ...)
2013-12-19 12:02 ` amker.cheng at gmail dot com
@ 2013-12-19 14:45 ` amker.cheng at gmail dot com
2013-12-20 10:28 ` amker.cheng at gmail dot com
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: amker.cheng at gmail dot com @ 2013-12-19 14:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #4 from bin.cheng <amker.cheng at gmail dot com> ---
First clue.
b_lsm.11_13 is recognized as chrec {1, +, 1}_2 with the patch, thus the loop
can be vectorized now.
<bb 5>:
<bb 6>:
# b.4_30 = PHI <b.4_12(5), 1(12)>
# prephitmp_28 = PHI <c.1_9(5), c.1_21(12)>
# b_lsm.11_13 = PHI <b.4_12(5), 1(12)>
# ivtmp_46 = PHI <ivtmp_45(5), 13(12)>
c.1_9 = prephitmp_28 | 1;
b.4_12 = b.4_30 + 1;
ivtmp_45 = ivtmp_46 - 1;
if (ivtmp_45 != 0)
goto <bb 5>;
else
goto <bb 7>;
Problem arises in calling stack like:
vect_do_peeling_for_loop_bound
slpeel_tree_peel_loop_to_edge
slpeel_update_phi_nodes_for_guard1
for phi node : # b_lsm.11_13 = PHI <b.4_12(5), 1(12)>
It looks like loop peeling has difficulty in coping with peeled phi node.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
2013-12-16 1:39 [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486 su at cs dot ucdavis.edu
` (4 preceding siblings ...)
2013-12-19 14:45 ` amker.cheng at gmail dot com
@ 2013-12-20 10:28 ` amker.cheng at gmail dot com
2014-01-02 15:52 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: amker.cheng at gmail dot com @ 2013-12-20 10:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #5 from bin.cheng <amker.cheng at gmail dot com> ---
For the offending loop:
<bb 5>:
<bb 6>:
# b.4_30 = PHI <b.4_12(5), 1(12)>
# prephitmp_28 = PHI <c.1_9(5), c.1_21(12)>
# b_lsm.11_13 = PHI <b.4_12(5), 1(12)>
# ivtmp_46 = PHI <ivtmp_45(5), 13(12)>
c.1_9 = prephitmp_28 | 1;
b.4_12 = b.4_30 + 1;
ivtmp_45 = ivtmp_46 - 1;
if (ivtmp_45 != 0)
goto <bb 5>;
else
goto <bb 7>;
Now SCEV recognizes b_lsm.11_13 as {1,1}_2, and vectorizer considers it can be
vectorized.
The problem comes in function slpeel_update_phi_nodes_for_guard1 for phi node
:# b_lsm.11_13 = PHI <b.4_12(5), 1(12)>. It's special because its loop_arg:
b.4_12 has already been handled in previous node and has non-null current
definition, resulting in assertion failure at line:
gcc_assert (get_current_def (current_new_name) == NULL_TREE);
It seems loop manipulating utility for vectorization can't cope with this kind
PEELED phi node.
We can get more loops vectorized if we can handle this issue in vectorization.
For example, the more complicated example reported can be vectorized
successfully.
But, I think it's a little bit difficult to handle the case because it's
possible to have the PEELED phi node come before the phi node from which it's
peeled from (b.4_30, in this case), just like:
<bb 5>:
<bb 6>:
# b_lsm.11_13 = PHI <b.4_12(5), 1(12)> <----appear before b.4_30
# b.4_30 = PHI <b.4_12(5), 1(12)>
# prephitmp_28 = PHI <c.1_9(5), c.1_21(12)>
# ivtmp_46 = PHI <ivtmp_45(5), 13(12)>
c.1_9 = prephitmp_28 | 1;
b.4_12 = b.4_30 + 1;
ivtmp_45 = ivtmp_46 - 1;
if (ivtmp_45 != 0)
goto <bb 5>;
else
goto <bb 7>;
So here I come up three options:
0) handle peeled phi in slpeel_update_phi_nodes_for_guard*. Maybe two passes
scanning for phi nodes is necessary.
1) reject loops containing peeled phi node in vectorization.
2) add code to rewrite such peeled phi node into normal one.
I am new to vectorization, so any words?
Thanks,
bin
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
2013-12-16 1:39 [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486 su at cs dot ucdavis.edu
` (5 preceding siblings ...)
2013-12-20 10:28 ` amker.cheng at gmail dot com
@ 2014-01-02 15:52 ` jakub at gcc dot gnu.org
2014-01-03 2:18 ` amker.cheng at gmail dot com
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-02 15:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 31562
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31562&action=edit
gcc49-pr59519.patch
I wonder if this isn't just a checking issue, the two PHI nodes created in
*new_exit_bb have the same argument, so I think it is just fine if the two PHI
results are used interchangeably, later optimization passes should hopefully
coalesce them into a single IV.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
2013-12-16 1:39 [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486 su at cs dot ucdavis.edu
` (6 preceding siblings ...)
2014-01-02 15:52 ` jakub at gcc dot gnu.org
@ 2014-01-03 2:18 ` amker.cheng at gmail dot com
2014-01-03 10:01 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: amker.cheng at gmail dot com @ 2014-01-03 2:18 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #7 from bin.cheng <amker.cheng at gmail dot com> ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 31562 [details]
> gcc49-pr59519.patch
>
> I wonder if this isn't just a checking issue, the two PHI nodes created in
> *new_exit_bb have the same argument, so I think it is just fine if the two
> PHI results are used interchangeably, later optimization passes should
> hopefully coalesce them into a single IV.
I tested one similar patch before. It passed x86_64 bootstrap and normal
regression test. It failed some ada (also one go) cases if I ran regression
test with "-O3" option. The failures look like noise to me, which I am not
sure about. What's your test results?
One potential shortage is it introduces additional PHI/copy of different ssa
names and makes the generated code some kind of ugly and hard to read, but just
as you pointed out, later passes should be able to coalescing them (I am not
sure about that, especially after seeing ssa names not get coalesced in some
more regular cases.)
Thanks.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
2013-12-16 1:39 [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486 su at cs dot ucdavis.edu
` (7 preceding siblings ...)
2014-01-03 2:18 ` amker.cheng at gmail dot com
@ 2014-01-03 10:01 ` jakub at gcc dot gnu.org
2014-01-03 10:08 ` amker.cheng at gmail dot com
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-03 10:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
BTW, the patch can hardly regress anything, it only affects cases that ICEd
before the patch.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
2013-12-16 1:39 [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486 su at cs dot ucdavis.edu
` (8 preceding siblings ...)
2014-01-03 10:01 ` jakub at gcc dot gnu.org
@ 2014-01-03 10:08 ` amker.cheng at gmail dot com
2014-01-03 10:24 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: amker.cheng at gmail dot com @ 2014-01-03 10:08 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #10 from bin.cheng <amker.cheng at gmail dot com> ---
(In reply to Jakub Jelinek from comment #9)
> BTW, the patch can hardly regress anything, it only affects cases that ICEd
> before the patch.
Em, I am worried if vectorization can handle peeled phi correctly for each
scenario before, because I barely know the implementation. That's why I looked
for your guys' suggestions in the first place.
Thanks.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
2013-12-16 1:39 [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486 su at cs dot ucdavis.edu
` (9 preceding siblings ...)
2014-01-03 10:08 ` amker.cheng at gmail dot com
@ 2014-01-03 10:24 ` jakub at gcc dot gnu.org
2014-01-03 13:22 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-03 10:24 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've tried even:
struct S { int f0; } d;
int a[8] = { 0 }, b, c, e, f;
void
foo (void)
{
for (; e < 1; e++)
{
for (b = 0; b < 7; b++)
{
c |= (a[b + 1] != 0);
if (d.f0)
break;
}
f += b;
}
}
where I've hoped get_current_def would be called on the problematic loop_arg,
but apparently it isn't (the only calls are the one changed in the patch).
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
2013-12-16 1:39 [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486 su at cs dot ucdavis.edu
` (10 preceding siblings ...)
2014-01-03 10:24 ` jakub at gcc dot gnu.org
@ 2014-01-03 13:22 ` jakub at gcc dot gnu.org
2014-01-04 11:23 ` jakub at gcc dot gnu.org
2014-01-04 12:03 ` jakub at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-03 13:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
--target_board=unix/-O3 testing showed no changes (except for the testcases in
the patch), on both x86_64-linux and i686-linux (on the former one including
ada testing).
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
2013-12-16 1:39 [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486 su at cs dot ucdavis.edu
` (11 preceding siblings ...)
2014-01-03 13:22 ` jakub at gcc dot gnu.org
@ 2014-01-04 11:23 ` jakub at gcc dot gnu.org
2014-01-04 12:03 ` jakub at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-04 11:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Sat Jan 4 11:23:16 2014
New Revision: 206333
URL: http://gcc.gnu.org/viewcvs?rev=206333&root=gcc&view=rev
Log:
PR tree-optimization/59519
* tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_guard1): Don't
ICE if get_current_def (current_new_name) is already non-NULL, as long
as it is a phi result of some other phi in *new_exit_bb that has
the same argument.
* gcc.dg/vect/pr59519-1.c: New test.
* gcc.dg/vect/pr59519-2.c: New test.
Added:
trunk/gcc/testsuite/gcc.dg/vect/pr59519-1.c
trunk/gcc/testsuite/gcc.dg/vect/pr59519-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop-manip.c
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
2013-12-16 1:39 [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486 su at cs dot ucdavis.edu
` (12 preceding siblings ...)
2014-01-04 11:23 ` jakub at gcc dot gnu.org
@ 2014-01-04 12:03 ` jakub at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-04 12:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-01-04 12:03 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-16 1:39 [Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486 su at cs dot ucdavis.edu
2013-12-16 17:19 ` [Bug tree-optimization/59519] " su at cs dot ucdavis.edu
2013-12-17 19:21 ` [Bug tree-optimization/59519] [4.9 Regression] " mpolacek at gcc dot gnu.org
2013-12-19 11:46 ` jakub at gcc dot gnu.org
2013-12-19 12:02 ` amker.cheng at gmail dot com
2013-12-19 14:45 ` amker.cheng at gmail dot com
2013-12-20 10:28 ` amker.cheng at gmail dot com
2014-01-02 15:52 ` jakub at gcc dot gnu.org
2014-01-03 2:18 ` amker.cheng at gmail dot com
2014-01-03 10:01 ` jakub at gcc dot gnu.org
2014-01-03 10:08 ` amker.cheng at gmail dot com
2014-01-03 10:24 ` jakub at gcc dot gnu.org
2014-01-03 13:22 ` jakub at gcc dot gnu.org
2014-01-04 11:23 ` jakub at gcc dot gnu.org
2014-01-04 12:03 ` jakub 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).