[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #36 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #35)
> Which means another possible candidate for the "bug" is darwin_binds_local_p

yeah... see below.

> > > .. but something similar must apply to PLT and targets with linker veneers ?
> > 
> > I don't know how IPA RA works in detail but obviously the target has to
> > expose this detail.  It looks like IPA RA causes us to add some notes to
> > call insns which are supposed to describe those details and there's
> > collect_fn_hard_reg_usage which looks at the target function (but likely
> > does not include the ABI details of the call itself, in this case the
> > resolver).


> @deftypevr {Target Hook} bool TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS
> Set to true if each call that binds to a local definition explicitly
> clobbers or sets all non-fixed registers modified by performing the call.
> That is, by the call pattern itself, or by code that might be inserted by the
> linker (e.g.@: stubs, veneers, branch islands), but not including those
> modifiable by the callee.  The affected registers may be mentioned explicitly
> in the call pattern, or included as clobbers in CALL_INSN_FUNCTION_USAGE.
> The default version of this hook is set to false.  The purpose of this hook
> is to enable the fipa-ra optimization.
> @end deftypevr

thanks for the pointer, I'll take a look at that when i have some cycles.
I guess it was never added at the time the IPA stuff was done... and somehow we
"got away with it" mostly.

> might be relevant - though when compiling for a shared library the call
> to ___UTF_8_put does not bind locally (but then IPA RA shouldn't apply
> either I guess).  So, does ___UTF_8_put bind locally?

extern void ___UTF_8_put
   (char* *ptr, unsigned int c)

If it does, then that's also a bug :), will have to check (sometime later).

(we are always building with fPIC for x86_64, snd don't specifically identify
that the result will be a shlib [all Darwin exes are DSOs too] -  although
Linux does identify shlibs as something special).