[Bug middle-end/92263] [10 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2087 since r270758

[wilson at gcc dot gnu.org]

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

--- Comment #6 from Jim Wilson <wilson at gcc dot gnu.org> ---
Looking at some other targets.  ARM has movcc but not 128-bit long double. 
Aaarch has movcc and 128-bit long double, but has 128-bit load/store so this is
only 4 instructions.  mips64, powerpc64, and sparc64 have movcc and 128-bit
long double, but emit the memcpy inline as 8 instructions.  riscv64 meanwhile
wants the libcall with -Os as that is 4 instructions instead of 8.  For rv32
this would be 16 instructions.  I'm not sure offhand if the other targets
support 32-bit code and 128-bit long double.

Anyways, I tracked the use of BLOCK_OP_NO_LIBCALL in emit_move_complex back to
bugzilla 15289, fixed by a patch from Richard Henderson back in Dec 1 2004.  I
think it is just an oversight that -Os wasn't considered here.  I think the
correct fix is to only force BLOCK_OP_NO_LIBCALL when optimizing for speed. 
With this change, I get the 8 instruction sequence with -O2, and the 4
instruction libcall sequence with -Os, which is what the RISC-V backend wants,
and this lets the testcase work.