http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53090
bin.cheng <amker.cheng at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amker.cheng at gmail dot com
--- Comment #2 from bin.cheng <amker.cheng at gmail dot com> ---
I tried the simple case, gcc doesn't work as expected on x86_64, but x86 is
fine.
I think there are several issues in ivopt causing this. The first issue is
IVOPT is too conservative when representing iv_use with iv_cand in type with
smaller precision.
Consider below use/cand:
use 0
address
in statement t_mp_11 = *_10;
at position *_10
type int *
base perm_9(D) + 4
step 4
base object (void *) perm_9(D)
related candidates
candidate 5 (important)
var_before ivtmp.8
var_after ivtmp.8
incremented before exit test
type unsigned int
base 1
step 1
candidate 6 (important)
original biv
type int
base 1
step 1
Use 0 is in type "int *" which has precision 64 on x86_64; cand is in type
"int" which has precision 32 on x86_64. In function get_computation_cost_at,
there is below code:
if (TYPE_PRECISION (utype) > TYPE_PRECISION (ctype))
{
/* We do not have a precision to express the values of use. */
return infinite_cost;
}
But this is too conservative because the loop runs for "(j-i)/2" times, which
can be expressed by the candidate. Even though the candidate has smaller type
than iv_use.
We should add some code checking loop niters against candidate's coverage here.
For example, the generated assembly changed into:
.L14:
movl (%rdx), %edi
movslq %eax, %rcx
addl $1, %eax
movl (%r15,%rcx,4), %esi
subq $4, %rdx
movl %edi, (%r15,%rcx,4)
movl %r8d, %ecx
subl %eax, %ecx
movl %esi, 4(%rdx)
cmpl %ecx, %eax
jl .L14
Now the original candidate is chosen as rcs for original induction variable
"i". Unfortunately there are some other issues which prevent IVOPT from
choosing right candidate for original induction variable "j".
I will keep looking into it see what's going on.
