Questions about vectorizing a simple loop by inferring the range from array
Hi,
I'm investigating how to vectorize the following simple case:
int A[1024 * 2];
int foo1 (unsigned offset) {
int sum = 0;
for (unsigned i = 0; i < 1024; i++)
sum += A[i + offset];
return sum;
}
The loop body and loop vectorizer dumps are:
# i_13 = PHI
# ivtmp_14 = PHI
_1 = offset_7(D) + i_13;
_2 = A[_1];
sum_8 = _2 + sum_11;
i_9 = i_13 + 1;
...
Creating dr for A[_1]
...
(chrec = (sizetype) {offset_7(D), +, 1}_1)
(res = (sizetype) {offset_7(D), +, 1}_1)
case1.c:7:13: missed: failed: evolution of offset is not affine.
As SCEV thinks {offset,+,1} may overflow, it can not propagate the sizetype and
fails. The call-stack is:
dr_analyze_innermost() ->
simple_iv() -> ... ->
convert_affine_scev() ->
scev_probably_wraps_p() ->
scev_var_range_cant_overflow()
loop_exits_before_overflow()
BTW. If we add a stmt like "if (offset <= 1024)" before the loop, GCC can
vectorized it successfully, as scev_var_range_cant_overflow() knows the range
of _1.
For the original case, I think GCC is able to infer the range from the array
length and do the vectorization. There is already functions to infer this info
from undefined behavior like array-ref and record nonwrappiong IVs. We can see
the dumps of passes like evrp, cunroll, vrp1, etc:
Induction variable (unsigned int) offset_8(D) + 1 * iteration does not wrap
in statement _2 = A[_1];
in loop 1.
Statement _2 = A[_1];
is executed at most 2047 (bounded by 2047) + 1 times in loop 1.
The call-stack is:
estimate_numbers_of_iterations() ->
infer_loop_bounds_from_undefined() ->
infer_loop_bounds_from_array() -> ... ->
record_nonwrapping_iv()
So, I have two questions:
1. is it legal to vectorize such case by inferring the no wrap info from array
ref (I'm wondering if there is any corner case that can not do)?
2. If the 1st question is true, then how could we implement this in GCC?
For the 2nd question, I think there may be several possible solutions:
- Could we re-use the existing nonwrapping IV information found by niter?
- Or, could we implement a function called infer_nowrapping_from_array() (like
infer_loop_bounds_from_array)? For this way, there are also different possible
places to call it:
- in the very beginning (i.e., dr_analyze_innermost()), where we knows it is
analyzing an array-ref A[_1].
- in scev_probably_wraps_p(), where it doesn't know it's analyzing an array
subscript, so we have to find if the user of _1 is array-ref (i.e., A[_1]).
As SCEV is the fundamental pass for loop analysis, I think we'd be very careful
about the correctness. Do you have any comments?
Thanks!
-Hao
Bug: GCC riscv building fails at self-tests with specific march
I encountered a bug when trying to build a RISC-V GCC cross-compiler. I believe that the most relevant configure options that I used are: --disable-multilib --with-arch=rv32ia --with-abi=ilp32 However, I can post a full list if needed. I have the GCC git tree located at the path "/home/quantum/devel/git/gcc" and am building it inside the sub-directory "build1". It seems to fail when attempting to build the self-tests. Here is an excerpt from the build output: /home/quantum/devel/git/gcc/build1/./gcc/xgcc -B/home/quantum/devel/git/gcc/build1/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=.././../gcc/testsuite/selftests /home/quantum/devel/git/gcc/build1/./gcc/xgcc -B/home/quantum/devel/git/gcc/build1/./gcc/ -xc++ -nostdinc /dev/null -S -o /dev/null -fself-test=.././../gcc/testsuite/selftests cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension It seems to be trying to build test suites that are in conflict with my march settings. Interestingly, I didn't have this issue when trying to build the release version tagged "releases/gcc-13.2.0". However, I wanted to use some newer features that were only merged less than a month ago. I tried to build the GIT tree and encountered this error. I attempted to bisect the issue and found that it only happens when gcc/DEV-PHASE is set to: experimental I'm not very familar with GCC's build system, but this suggests to me that the tests are only conditionally built on experimental/development codebase snapshots. Michael T. Kloos
Re: Bug: GCC riscv building fails at self-tests with specific march
Sorry for the formatting break. Resending... I encountered a bug when trying to build a RISC-V GCC cross-compiler. I believe that the most relevant configure options that I used are: --disable-multilib --with-arch=rv32ia --with-abi=ilp32 However, I can post a full list if needed. I have the GCC git tree located at the path "/home/quantum/devel/git/gcc" and am building it inside the sub-directory "build1". It seems to fail when attempting to build the self-tests. Here is an excerpt from the build output: /home/quantum/devel/git/gcc/build1/./gcc/xgcc -B/home/quantum/devel/git/gcc/build1/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=.././../gcc/testsuite/selftests /home/quantum/devel/git/gcc/build1/./gcc/xgcc -B/home/quantum/devel/git/gcc/build1/./gcc/ -xc++ -nostdinc /dev/null -S -o /dev/null -fself-test=.././../gcc/testsuite/selftests cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension cc1plus: error: '-mdiv' requires '-march' to subsume the 'M' extension It seems to be trying to build test suites that are in conflict with my march settings. Interestingly, I didn't have this issue when trying to build the release version tagged "releases/gcc-13.2.0". However, I wanted to use some newer features that were only merged less than a month ago. I tried to build the GIT tree and encountered this error. I attempted to bisect the issue and found that it only happens when "gcc/DEV-PHASE" is set to: experimental I'm not very familar with GCC's build system, but this suggests to me that the tests are only conditionally built on experimental/development codebase snapshots. Michael T. Kloos
gcc-11-20231109 is now available
Snapshot gcc-11-20231109 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20231109/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision 2206a4b74ce6d7743669b96d127b937305a7b7c8 You'll find: gcc-11-20231109.tar.xz Complete GCC SHA256=4e8a962c96a6290e63be6056249fe2cd3c1d3f831b32b88ca9cb82656d3ca0b2 SHA1=2c45b59af98b0c37a57db214b74b8f6af2e8f10f Diffs from 11-20231102 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
yyyÿyy
Sent from my iPhone
