On Wed, 2020-08-26 at 09:02 -0300, Alexandre Oliva wrote: > 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? Agreed. Sorry if I wasn't clear that generic code + a hook should be sufficient.
jeff
