Created attachment 24311 [details] Output of "ajo-gcc -std=c99 -w -O1 -funswitch-loops -ftree-vectorize -fno-tree-fre test.c -v" This reproduces for me with svn revision 173843 (2011-05-17). It doesn't reproduce with gcc 4.5.1. I'm on Ubuntu 10.10, x86-64. cat >test.c <<EOF volatile unsigned char g_324[4] = {0, 1, 0, 1}; int x, y; void func_81() { int l_466, l_439[7] = {0}; lbl_473: if (x) { for (int g_97 = 0; (g_97 < 4); ++g_97) { if (y) goto lbl_473; g_324[g_97]; l_466 = l_439[g_97]; } foo(l_466); } } EOF gcc -std=c99 -w -O1 -funswitch-loops -ftree-vectorize -fno-tree-fre test.c test.c: In function ‘func_81’: test.c:3:6: internal compiler error: in vect_enhance_data_refs_alignment, at tree-vect-data-refs.c:1551 This test case is reduced from the output of Csmith 2.1.0 (git hash 01aa8b04, https://github.com/Quuxplusone/csmith/), using the following command line: csmith --no-paranoid --no-longlong --no-pointers --arrays --jumps --consts --volatiles --no-checksum --no-divs --no-muls --no-bitfields --packed-struct -s 799267216
Confirmed.
It is caused by revision 166244: http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00130.html
The problem here is that vol.2_8 ={v} g_324[g_97_22]; is skipped during determination of the vectorization factor, because it has no uses. The vf is set to 4, and then the analysis fails on the char data-ref. I think we should just not vectorize when there is a volatile access in a loop. Is that reasonable? Thanks, Ira
On Tue, 31 May 2011, irar at il dot ibm.com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093 > > Ira Rosen <irar at il dot ibm.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |irar at il dot ibm.com > > --- Comment #3 from Ira Rosen <irar at il dot ibm.com> 2011-05-31 07:31:02 UTC --- > The problem here is that > vol.2_8 ={v} g_324[g_97_22]; > is skipped during determination of the vectorization factor, because it has no > uses. The vf is set to 4, and then the analysis fails on the char data-ref. > > I think we should just not vectorize when there is a volatile access in a loop. > Is that reasonable? I think that's reasonable for 4.6. But we don't need to make data-ref analysis fail just because of volatile references - we for example can easily unroll a loop with volatile loads/stores. Of course this case seems to be special - how do we deal with stmts with no uses during vectorization? Or do we assume they don't happen because usually DCE gets rid of them? Richard.
(In reply to comment #4) > I think that's reasonable for 4.6. But we don't need to make > data-ref analysis fail just because of volatile references - we for > example can easily unroll a loop with volatile loads/stores. > > Of course this case seems to be special - how do we deal with > stmts with no uses during vectorization? Or do we assume > they don't happen because usually DCE gets rid of them? We ignore them. But this is under the assumption that they don't have memory accesses. Ira > > Richard.
On Tue, 31 May 2011, irar at il dot ibm.com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093 > > --- Comment #5 from Ira Rosen <irar at il dot ibm.com> 2011-05-31 08:30:49 UTC --- > (In reply to comment #4) > > > I think that's reasonable for 4.6. But we don't need to make > > data-ref analysis fail just because of volatile references - we for > > example can easily unroll a loop with volatile loads/stores. > > > > Of course this case seems to be special - how do we deal with > > stmts with no uses during vectorization? Or do we assume > > they don't happen because usually DCE gets rid of them? > > We ignore them. But this is under the assumption that they don't have memory > accesses. Ah, I see. Yes, I guess not vectorizing for volatiles is the way to go then. Richard.
I am testing this patch then: Index: tree-vect-data-refs.c =================================================================== --- tree-vect-data-refs.c (revision 174467) +++ tree-vect-data-refs.c (working copy) @@ -2584,6 +2584,16 @@ vect_analyze_data_refs (loop_vec_info lo return false; } + if (TYPE_VOLATILE (TREE_TYPE (DR_REF (dr)))) + { + if (vect_print_dump_info (REPORT_UNVECTORIZED_LOCATIONS)) + { + fprintf (vect_dump, "not vectorized: volatile type "); + print_gimple_stmt (vect_dump, stmt, 0, TDF_SLIM); + } + return false; + } + base = unshare_expr (DR_BASE_ADDRESS (dr)); offset = unshare_expr (DR_OFFSET (dr)); init = unshare_expr (DR_INIT (dr)); Thanks, Ira
On Tue, 31 May 2011, irar at il dot ibm.com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093 > > --- Comment #7 from Ira Rosen <irar at il dot ibm.com> 2011-05-31 09:06:04 UTC --- > I am testing this patch then: > > Index: tree-vect-data-refs.c > =================================================================== > --- tree-vect-data-refs.c (revision 174467) > +++ tree-vect-data-refs.c (working copy) > @@ -2584,6 +2584,16 @@ vect_analyze_data_refs (loop_vec_info lo > return false; > } > > + if (TYPE_VOLATILE (TREE_TYPE (DR_REF (dr)))) if (TREE_THIS_VOLATILE (DR_REF (dr))) instead. Richard.
(In reply to comment #8) > > > > + if (TYPE_VOLATILE (TREE_TYPE (DR_REF (dr)))) > > if (TREE_THIS_VOLATILE (DR_REF (dr))) > > instead. > OK. Thanks. Ira > Richard.
Author: irar Date: Tue May 31 12:31:04 2011 New Revision: 174477 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174477 Log: PR tree-optimization/49093 * tree-vect-data-refs.c (vect_analyze_data_refs): Fail for volatile data references. Added: trunk/gcc/testsuite/gcc.dg/vect/pr49093.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
Author: irar Date: Thu Jun 2 07:02:57 2011 New Revision: 174559 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174559 Log: PR tree-optimization/49093 * tree-vect-data-refs.c (vect_analyze_data_refs): Fail for volatile data references. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/vect/pr49093.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-vect-data-refs.c
Fixed.