On Thu, 14 Jul 2011, Ulrich Weigand wrote: > Jeff Law wrote: > > On 06/15/11 21:46, Hans-Peter Nilsson wrote: > > > PR rtl-optimization/48542 > > > * reload.c (find_equiv_reg): Stop looking when finding a > > > setjmp-type call. > > > * reload1.c (reload_as_needed): Invalidate all reload > > > registers when crossing a setjmp-type call. > > OK. > > Jeff > > I see that this went already in, but I'm wondering why this > change should be necessary. As far as register use is > concerned, setjmp ought to behave just like a regular function: > if a register is call-clobbered, reload will not attempt to > use it across a function call (*any* function call) anyway; > but if the register is call-saved, setjmp really ought to > restore the old value, *both* times it returns, and so reuse > ought to be allowed ...
First of all, if this changes (back) in reload, then it should change in IRA too. Right; you do have a point. I *think* my excuse would be that I stopped thinking further when I saw that IRA doesn't allocate registers across setjmp. Changing this will make a difference for architectures (ABIs) that don't save call-saved registers in the prologue but rather for each call. Crazy and suboptimal? Not if you use register windows or a register stack where you just (automatically as part of the call insn or sequence) update a register number or pointer for the call "save". So MMIX is one, I guess sparc and ia64 could be others, it seems so at a glance. It all depends on their setjmp/longjmp implementations of course, I don't have the whole picture. If you change this, such ports will then have to handle calls to setjmp differently to other functions; not call-save across those setjmp calls or else the call-saved register will be picked up instead of the one saved at setjmp (restored at longjmp). The difference would be better code across calls to setjmp (and related secondary effects in the setjmp-calling function) for everyone else, but what is in place with the committed patch now *is* consistent and correct and not needing special handling regarding register-saving, AFAICT. brgds, H-P