This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, ivopts] Handle type-converted IVs better


Roger Sayle writes:
> I'll consider it for mainline, if you can describe/provide a testcase
> where we've regressed and that is restored by your patch.

Sure.

This is the testcase from my original email:

  long last_data_offset;
  int store;
  char *data;
  
  f ()
  {
  
    long data_offset = last_data_offset;
    char *p;
  
    for (p = data; *p; p++)
      {
        data_offset++;
        g (data_offset);
        store = data_offset + 1;
      }
  }

The MIPS64 assembly with 3.4.4 for the loop is:

$L9:
        jal     g
        daddiu  $16,$16,1

        daddiu  $17,$17,1
        sw      $16,%gp_rel(store)($28)
        lb      $2,0($17)
        bne     $2,$0,$L9
        move    $4,$16

Nice.  Mainline without the patch looks like this:

$L4:
        daddiu  $16,$16,1
        move    $4,$16
        jal     g
        daddiu  $17,$17,1

*       sll     $3,$18,0
*       addu    $3,$3,$19
        sw      $3,%gp_rel(store)($28)
        lb      $2,0($17)
        bne     $2,$0,$L4
*       daddiu  $18,$18,1

Marked are the unnecessary instructions wasted on maintaining the
additional IV.

Mainline with the patch is still not perfect but better:

$L9:
        move    $4,$16
        jal     g
        daddiu  $17,$17,1

*       sll     $3,$16,0
*       addiu   $3,$3,1
        sw      $3,%gp_rel(store)($28)
        lb      $2,0($17)
        bne     $2,$0,$L9
        daddiu  $16,$16,1

Mainline truncates too early which seems like another regression.  But
anyway point is that there is no reason to add another induction
variable (additional register, extra instruction to maintain it) since
we can compute the same value using an existing IV.

> If it can be made into a new dejagnu test for the testsuite, even
> better.

No unfortunately, at least not yet.  I don't think there is
infrastructure for checking the number of induction variables ivopts
determines.  I am planning to do something about this though.

Adam


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]