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. Peter
