On Aug 15, 2015, at 9:19 AM, Richard Sandiford <rdsandif...@googlemail.com>
wrote:
> Mike Stump <mikest...@comcast.net> writes:
>> On Aug 15, 2015, at 3:32 AM, Richard Sandiford
>> <rdsandif...@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.
