[Bug tree-optimization/58686] vect_get_loop_niters() fails for some loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58686 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/58686] vect_get_loop_niters() fails for some loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58686
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-12-12
--- Comment #4 from Andrew Pinski ---
Confirmed.
#define N 5
void foo(int* a, unsigned int i)
{
int j = 0;
do
{
a[j++] = 0;
i -= 4;
}
while (i >= N);
}
CUT ---
LLVM can convert the above loop into a memset while GCC does not.
[Bug tree-optimization/58686] vect_get_loop_niters() fails for some loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58686
--- Comment #3 from rguenther at suse dot de rguenther at suse dot de ---
congh at google dot com gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58686
--- Comment #2 from Cong Hou congh at google dot com ---
I think this issue is more like a missed optimization.
If the iteration number can be calculated as a constant value at
compile time,
then the function assert_loop_rolls_lt() won't be called due to an
early exit
(specifically in the function number_of_iterations_lt() at the call to
number_of_iterations_lt_to_ne()). That is why I could not craft a
testcase
showing miscompile.
A better test case is shown below:
#define N 4
void foo(int* a, unsigned int i)
{
int j = 0;
do
{
a[j++] = 0;
i -= 4;
}
while (i = N);
}
Compile it with -O3 and the produced result is using __builtin_memset()
as the
niter can be calculated. But if the value of N is replaced by others
like 3 or
5, GCC won't optimize this loop into __builtin_memset() any more.
Yeah, the issue in general is finding a condition that ensures the loop will
terminate and a formula that computes the number of iterations if that holds
true. In case of wrapping arithmetic this is non-trivial and likely not all
cases are implemented.
Richard.
[Bug tree-optimization/58686] vect_get_loop_niters() fails for some loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58686 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization CC||rakdver at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Blocks||53947 Summary|[BUG] |vect_get_loop_niters() |vect_get_loop_niters() |fails for some loops |cound not get the correct | |result for some loops. | --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- You mention several things that sound like they may lead to wrong code. Based on your analysis, can you construct testcases that show a miscompile? Easiest would be to trick niter analysis to think a loop runs just once so it is peeled completely. Best have different bugreports for the (possible) wrong-code issues as this bug starts about a missed optimization. [versioning for niter may be a possible solution, in case we can build proper conditions in niter-assumptions]
[Bug tree-optimization/58686] vect_get_loop_niters() fails for some loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58686
--- Comment #2 from Cong Hou congh at google dot com ---
I think this issue is more like a missed optimization.
If the iteration number can be calculated as a constant value at compile time,
then the function assert_loop_rolls_lt() won't be called due to an early exit
(specifically in the function number_of_iterations_lt() at the call to
number_of_iterations_lt_to_ne()). That is why I could not craft a testcase
showing miscompile.
A better test case is shown below:
#define N 4
void foo(int* a, unsigned int i)
{
int j = 0;
do
{
a[j++] = 0;
i -= 4;
}
while (i = N);
}
Compile it with -O3 and the produced result is using __builtin_memset() as the
niter can be calculated. But if the value of N is replaced by others like 3 or
5, GCC won't optimize this loop into __builtin_memset() any more.
