[Bug target/82012] [8 Regression] libitm build fails for s390x-linux-gnu

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 29 Aug 2017, krebbel at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82012
> 
> --- Comment #3 from Andreas Krebbel <krebbel at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #1)
> ...
> > inline int __attribute__((always_inline)) foo () { return 0; }
> > int __attribute__((target("soft-float"))) test () { return foo (); }
> > 
> > 
> > s390 misses to implement TARGET_CAN_INLINE_P.
> 
> Well, but what should the can_inline_p hook answer in that case? Since
> soft-float/hard-float is an ABI switch the hook probably should reject
> inlining.  But that would not be helpful. What about ignoring differences of
> target attributes if the callee has been declared "always_inline"? If the
> programmer uses always_inline it means that the function is expected to inherit
> the target attributes of the caller. This should be part of the default
> implementation of the can_inline_p hook then.

Not sure.  The user might be deliberately expecting an error when
such function is called from wrong target context.  The function
might contain inline assembly which violates the callers ABI
(in this case it might contain hard-float code?).

Not sure what the libitm use of soft-float is about here.

Note the previous implementation simply treated "no target attribute"
as "generic".  Somewhat reasonable at first sight but it breaks badly
because we do not really know this property and all functions implicitely
inherit "target" from the global set options (with LTO that gets
explicit to support TUs with different global flags).

I'd say it is valid to inline any function not using FP into
a function that differs in "soft-float" state?  Similar to the
patch I did to the x86 backend allowing -mfpmath differences
in that case.

Would probably fix this particular case.

Consider a flag enabling some vector features, -mfancy-vect, building
a TU with said flag and

inline void __attribute__((always_inline)) foo ()
{
  __builtin_fancy_vect_insn ();
}

void __attribute__((target("no-fancy-vect")))
{
  return foo ();
}

with the pre-patched default hook we'd happily inline foo () here
(it doesn't have a target attribute!).

Note at runtime such inlining should be always valid(?) (arm folks
make thumb vs. non-thumb as an example - not sure if the linker
needs to insert special dispatch code when transitioning, so it
might not be ok in that case!).  But as insn patterns are
usually guarded with some insn-enablement conditions we'd ICE.