https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82012
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On August 30, 2017 10:24:09 AM GMT+02:00, "krebbel at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >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?! Well, RA runs after inlining so only inline-asm might be affected. >... >> > 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!
