Re: Clean up MIPS branch handling, fix mips-ps-*.c failures

[Adam Nemet <anemet at sonic dot net>]

Adam Nemet <anemet@caviumnetworks.com> writes:
> The remaining pessimizations have this form:
>
> -       bgez    $2,$L4068
> +       dsrl    $2,$2,63
> +       sll     $2,$2,0
> +       beq     $2,$0,$L4068
>
> I was trying to come up with a small testcase for this yesterday but I
> couldn't.  I will look into it more later today.  Also note that the
> truncation is in the way of recognizing that this is just a branch on
> the sign-bit.  My patch to expose truncates to the middle-end should
> eliminate the truncation here but I guess it is still better to
> understand the issue as it is.

Since then I found a testcase for this:

  typedef struct rtx_def *rtx;
  enum reg_class
  { ALL_COP_AND_GR_REGS, ST_REGS, ALL_REGS, LIM_REG_CLASSES };
  enum reload_type
  { RELOAD_FOR_OTHER_ADDRESS };
  struct reload
  {
    rtx in;
    int opnum;
    enum reload_type when_needed;
    unsigned int optional:1;
  };
  extern struct reload rld[(2 * 30 * (1 + 1))];
  push_reload (rtx in, int i, int optional)
  {
    if (rld[i].optional && optional)
      remove_address_replacements ();
  }

I also checked the testcase with my truncation patch.  The patch
eliminates the truncation and then combine is able to simplify into
the sign-bit branch.

It turns out that it was a fairly lucky coincidence between
combine_simplify_rtx and if_then_else_cond that allowed the above
simplication before your patch.  combine_simplify_rtx believed based
on the mode that this was a comparison in a store-condition-code
context and changed the equality comparison into an xor:

  (eq:SI (truncate:SI (reg:DI 206)) (const_int 0)) 
  -> (xor:SI (truncate:SI (reg:DI 206)) (const_int 1))

Then if_then_else_cond since now it is not trivial whether the
expression can only have to values looked inside and eliminated the
TRUNCATE:

  -> (eq:SI (reg:DI 206) (const_int 0))

Since now the TRUNCATE has been eliminated, the shift and the
comparison get combined and simplify_comparison turns the combination
into a GE comparison.

To summarize, I think it is fair to say that eliminating the redundant
truncation is a more robust solution in this case .  So I don't think
we should do anything about this until then.

Regarding the other more relevant regression which has to do with
simplify_relational_operation_1 no longer optimizing our conditional
branches I will try to post something tomorrow.  In case you want to
look into it while I am asleep this is a possible testcase:

  void s (int n) 
  { 
    if (n--) 
      f (n); 
  } 
 
Adam