On Aug 25, 2020, Jeff Law <l...@redhat.com> wrote: > On Tue, 2020-08-25 at 02:16 -0300, Alexandre Oliva wrote: >> On Aug 24, 2020, Richard Biener <rguent...@suse.de> wrote: >> >> > since the option is quite elaborate on what (sub-)set of regs is >> > supposed to be cleared I'm not sure an implementation not involving >> > any target hook is possible? >> >> I don't think this follows. Machine-independent code has a pretty good >> notion of what registers are call-saved or call-clobbered, which ones >> could be changed in this regard for function-specific calling >> conventions, which ones may be used by a function to hold its return >> value, which ones are used within a function... >> >> It *should* be possible to introduce this in machine-independent code, >> emitting insns to set registers to zero and regarding them as holding >> values to be returned from the function. Machine-specific code could >> use more efficient insns to get the same result, but I can't see good >> reason to not have a generic fallback implementation with at least a >> best-effort attempt to offer the desired feature. > I think part of the problem here is you have to worry about stubs which can > change caller-saved registers. Return path stubs aren't particularly common, > but > they do exist -- 32 bit hpux for example :(
This suggests that such targets might have to implement the target-specific hook to deal with this, but does it detract in any way from the notion of having generic code to fall back to on targets that do NOT require any special handling? -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer
