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.


Reply via email to