On Wed, Oct 19, 2022 at 8:16 PM Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > > On 10/18/22 11:35, Palmer Dabbelt wrote: > > > >> I would have expected things to work fine with libcalls, perhaps with > >> the exception of the save/restore libcalls. So that needs deeper > >> investigation. > > > > The save/restore libcalls only support saving/restoring a handful of > > register configurations (just the saved X registers in the order > > they're usually saved in by GCC). It should be OK for correctness to > > over-save registers, but it kind of just un-does the shrink wrapping > > so not sure it's worth worrying about at that point. > > > > There's also some oddness around the save/restore libcall ABI, it's > > not the standard function ABI but instead a GCC-internal one. IIRC it > > just uses the alternate link register (ie, t0 instead of ra) but I may > > have forgotten something else. > > I hadn't really dug into it -- I was pretty sure they weren't following > the standard ABI based on its name and how I've used similar routines to > save space on some targets in the past. So if we're having problems > with shrink-wrapping and libcalls, those two might be worth investigating. > > > But I think the most important takeaway is that shrink wrapping should > work with libcalls, there's nothing radically different about libcalls > that would make them inherently interact poorly with shrink-wrapping. > So that aspect of the shrink-wrapping patch needs deeper investigation. >
Based on the feedback from both of you that shrink wrapping and libcall save/restore should work fine I'll try to lift that restriction again and investigate further what happens. Manolis > Jeff
