https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118328
--- Comment #2 from Richard Sandiford <rsandifo at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #1) > Note most of the use cases in my view for these attributes. These attributes > are there specifically to work around the fact that llvm does not do ipa ra > and the compiler does not record which registers are already preserved. I think the use case for preserve_none is a bit different from IPA RA, at least in the CPython case. IPA RA is about optimising callers based on information about callees, but preserve_none is instead about optimising the callees themselves (regardless of who the caller might be). If a function consists of a long chain of musttail calls, then it's relatively unlikely that saving and restoring registers “for the caller” will be beneficial. Each call in the musttail chain would need to save and restore the same call-preserved registers (if the function uses the registers internally). E.g. if you have f1 tail calling to f2, tail calling to f3, ... tail calling to f100, and all 100 functions use X19, you'll get 100 saves and restore of X19, all for one unknown caller. It's more efficient to tell the caller that it must preserve X19 itself. > I suspect gcc code generation is already decent . My impression from the CPython issue was that the GCC code quality wasn't acceptable without the attribute, but I agree that that's implied rather than explicit.
