Re: [PATCH][MIPS] Fix register renaming in the interrupt handlers

[Mike Stump <mikestump at comcast dot net>]

On Aug 15, 2015, at 9:19 AM, Richard Sandiford <rdsandiford@googlemail.com> wrote:
> Mike Stump <mikestump@comcast.net> writes:
>> On Aug 15, 2015, at 3:32 AM, Richard Sandiford
>> <rdsandiford@googlemail.com> wrote:
>>> 
>>> The port is only buggy if they have define_peephole2s with match_scratches
>>> and those match_scratches require a register that would be saved by
>>> an interrupt function.  In other cases defining T_H_R_S_O would have
>>> no effect (but still be a good idea for future proofing -- obviously
>>> someone who adds a new define_peephole2 is unlikely to be thinking
>>> about inerrupt functions).
>> 
>> Yeah, that was my reading of the code after I posted as well.  My port
>> was buggy.  :-( I think all the other ports like likely buggy or
>> suboptimal.
> 
> Suboptimal how?

Inability to use some registers.  Hum, maybe that can’t happen for other reasons.

> I don't see how that helps.

Maybe I’m envisioning something you aren’t proposing.  Anyway, a nice fix for this has code like:

      /* If this is a CALL_INSN, all call used registers are stored with                                                                                                                             
         unknown values.  */
      if (CALL_P (insn))
        {
          for (i = FIRST_PSEUDO_REGISTER - 1; i >= 0; i--)
            {
              if (call_used_regs[i])
                /* Reset the information about this register.  */
                reg_mode[i] = VOIDmode;
            }
        }

being updated so that at least for some calls to an interrupt function, the mode of the reg isn’t set to VOIDmode.  I didn’t choose this for any specific reason, I just grabbed a random use of call_used_regs that likely is wrong or less than optimal.  In the type of fix I envision, it would/could address this.

> The third in my list is still there unless you disable -fipa-ra.

Maybe I was railing against something you’re not proposing.  Anyway, safe to defer til we have more detail.