[Bug target/53090] suboptimal ivopt

[amker.cheng at gmail dot com]

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.