> On Thu, Feb 29, 2024 at 03:15:30PM +0100, Jan Hubicka wrote: > > I am not wed to the idea (just it appeared to me as an option to > > disabling this optimization by default). I still think it may make sense. > > Maybe I misunderstood your idea. > So, you are basically suggesting to go in a completely opposite direction > from H.J.'s changes, instead of saving less in noreturn prologues, save > more, most likely not change anything in code generation on the caller's > side (nothing is kept alive across visible unconditional noreturn calls) > and maybe after some time use normally caller-saved registers in say call > frame debug info for possible use in DW_OP_entry_value (but in that case it > is an ABI change) and improve debuggability of vars which live in normally > caller-saved registers right before a noreturn call in that frame? > What about registers in which function arguments are passed?
Hmm, you are right - I got it backwards. > > If it is done as a change with no changes at all on the caller side and > just on the callee side, it could again be guarded by some option (not sure > what the default would be) where the user could increase debuggability of > the noreturn caller (in that case always necessarily just a single immediate > one; while not doing the callee saved register saves improves debuggability > in perhaps multiple routines in the call stack, depending on which registers > wouldn't be saved and which registers are used in each of the caller frames; > e.g. noreturn function could save/not save all of %rbx, %r1[2345], one > caller somewhere use %r12, another %rbx and %r13, yet another one %r14 and > %r15). I am not sure how much practical value this would get, but in any case it is indpeendent of the discussed patch. Sorry for the confussion, Honza > > Jakub >
