I have a simple reduction test. (attachment to follow) I'm compiling it with: ../ppc_build/gcc/cc1 -mcpu=G4 -maltivec -O3 -ftree-vectorize reductest.c If the types are all unsigned, the loop is vectorized. If the types are all signed, the vectorizer bails because it doesn't know some pattern and there are suspicious unsigned types in the log: reductest.c:8: note: Detected induction. reductest.c:8: note: === vect_mark_stmts_to_be_vectorized === reductest.c:8: note: init: phi relevant? ivtmp.30_19 = PHI <ivtmp.30_18(2), 512(0)>; reductest.c:8: note: init: phi relevant? sum_22 = PHI <sum_13(2), 0(0)>; reductest.c:8: note: init: phi relevant? i_21 = PHI <i_15(2), 0(0)>; reductest.c:8: note: init: phi relevant? a_20 = PHI <a_14(2), a_6(0)>; reductest.c:8: note: init: stmt relevant? <L0>: reductest.c:8: note: init: stmt relevant? D.1686_9 = *a_20 reductest.c:8: note: init: stmt relevant? D.1687_10 = (short unsigned int) D.1686_9 reductest.c:8: note: init: stmt relevant? sum.0_11 = (short unsigned int) sum_22 reductest.c:8: note: init: stmt relevant? D.1689_12 = D.1687_10 + sum.0_11 reductest.c:8: note: init: stmt relevant? sum_13 = (short int) D.1689_12 reductest.c:8: note: vec_stmt_relevant_p: used out of loop. reductest.c:8: note: mark relevant 0, live 1. reductest.c:8: note: init: stmt relevant? a_14 = a_20 + 2B reductest.c:8: note: init: stmt relevant? i_15 = i_21 + 1 reductest.c:8: note: init: stmt relevant? ivtmp.30_18 = ivtmp.30_19 - 1 reductest.c:8: note: init: stmt relevant? if (ivtmp.30_18 != 0) goto <L6>; else goto <L2>; reductest.c:8: note: init: stmt relevant? <L6>: reductest.c:8: note: worklist: examine stmt: sum_13 = (short int) D.1689_12 reductest.c:8: note: vect_is_simple_use: operand D.1689_12 reductest.c:8: note: def_stmt: D.1689_12 = D.1687_10 + sum.0_11 reductest.c:8: note: type of def: 2. reductest.c:8: note: worklist: examine use 2: D.1689_12 reductest.c:8: note: mark relevant 0, live 1. reductest.c:8: note: worklist: examine stmt: D.1689_12 = D.1687_10 + sum.0_11 reductest.c:8: note: vect_is_simple_use: operand D.1687_10 reductest.c:8: note: def_stmt: D.1687_10 = (short unsigned int) D.1686_9 reductest.c:8: note: type of def: 2. reductest.c:8: note: worklist: examine use 2: D.1687_10 reductest.c:8: note: mark relevant 0, live 1. reductest.c:8: note: vect_is_simple_use: operand sum.0_11 reductest.c:8: note: def_stmt: sum.0_11 = (short unsigned int) sum_22 reductest.c:8: note: type of def: 2. reductest.c:8: note: worklist: examine use 2: sum.0_11 reductest.c:8: note: mark relevant 0, live 1. reductest.c:8: note: worklist: examine stmt: sum.0_11 = (short unsigned int) sum_22 reductest.c:8: note: vect_is_simple_use: operand sum_22 reductest.c:8: note: def_stmt: sum_22 = PHI <sum_13(2), 0(0)>; reductest.c:8: note: Unsupported pattern. reductest.c:8: note: not vectorized: unsupported use in stmt. reductest.c:8: note: unexpected pattern. reductest.c:8: note: vectorized 0 loops in function. I have not yet checked out the 4.1 tip or mainline to try this there...
Created attachment 12304 [details] Test to try signed/unsigned reductions A simple reduction test. Change WHATSIGN between "signed" and "unsigned" to try different signedness. "unsigned" seems to work, "signed" fails.
This is a known issue as C standard requires the short to be promoted to an int. This has nothing to do with the autovect except it cannot handle this case yet.
This is a dup of bug 26128. *** This bug has been marked as a duplicate of 26128 ***
By the way, the testcase gets vectorized if you compile with -fwrapv.