https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82012
--- Comment #7 from Andreas Krebbel <krebbel at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #6) ... > IPA computes this for us, but only somewhat as it looks for FP expressions > only (hopefully taking all inline asm as containing FP expressions) but > not disallowing FP value loads/stores. See i386.c:ix86_can_inline_p: > > else if (caller_opts->x_ix86_fpmath != callee_opts->x_ix86_fpmath > /* If the calle doesn't use FP expressions differences in > ix86_fpmath can be ignored. We are called from FEs > for multi-versioning call optimization, so beware of > ipa_fn_summaries not available. */ > && (! ipa_fn_summaries > || ipa_fn_summaries->get > (cgraph_node::get (callee))->fp_expressions)) > > this means the RA would have to load/store to non-FPR registers > which is what soft-float should guarantee. I think even FP expressions > should work, dispatching to soft-float routines? So IPA should > compute a inline_asm flag (but even that would need to name FPRs > in the constraints explicitely to be a problem I guess). -msoft-float is supposed to prevent any use of FPRs. With -mhard-float FPRs might be used as spill slots also for integer expressions and we also emit FPR<->GPR loads in the function prologue and epilogue in order to avoid allocating stack if not necessary. These case would probably not be catched by the IPA fp accounting - right?! ... > > So for S/390 I currently would tend to always allow inlining regardless of > > the > > target attributes hoping that the majority of problems would be catched > > (with > > obscure error messages mostly). > > ICEs you mean, or assembler errors. > > On x86 we avoid the inlining to not run into obscure ICEs (but got hit > with inline failure errors with -flto due to the "bugs"). Ok, I'll try to do the same for s390. Thanks!
