On 03/02/2018 08:28 PM, Peter Bergner wrote:
> On 3/2/18 3:26 PM, Jeff Law wrote:
>> On 03/02/2018 12:45 PM, Peter Bergner wrote:
>>> ...which forces us to spill everything live across the setjmp by forcing
>>> the pseudos to interfere all hardregs. That can't be good for performance.
>>> What am I missing?
>>
>> You might want to hold off a bit. I've got changes for 21161 which can
>> help this significantly. Basically the live-across-setjmp set is way
>> too conservative -- it includes everything live at the setjmp, but it
>> really just needs what's live on the longjump path.
>>
>> As for why, I believe it's related to trying to make sure everything has
>> the right values if we perform a longjmp.
>
> I can understand why we might save/restore across functions that can throw
> exceptions since the program state hasn't been saved at the point of the
> call or in the call, but what is special about setjmp()? We don't need
> to save/restore the volatile regs since all functions clobber them and
> the non-volatile regs are saved/restored by setjmp(), just like any
> normal function call. ...and as far as I know, setjmp() doesn't save
> or restore the stack contents, just the stack pointer, pc, etc.
> So I guess I still don't know why we treat it differently than any
> other function call wrt register allocation.
Here's the comment from regstat.c:
/* We have a problem with any pseudoreg that lives
across the setjmp. ANSI says that if a user variable
does not change in value between the setjmp and the
longjmp, then the longjmp preserves it. This
includes longjmp from a place where the pseudo
appears dead. (In principle, the value still exists
if it is in scope.) If the pseudo goes in a hard
reg, some other value may occupy that hard reg where
this pseudo is dead, thus clobbering the pseudo.
Conclusion: such a pseudo must not go in a hard
reg. */
