https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #24 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 10 Sep 2021, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154 > > --- Comment #23 from Segher Boessenkool <segher at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #21) > > > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: error: > > > unrecognizable insn: > > > 704 | func parseFloatPrefix(s string, bitSize int) (float64, int, > > > error) { > > > | ^ > > > (insn 351 350 352 35 (set (reg:SF 219 [ SR.5776 ]) > > > (subreg:SF (reg:DI 237 [ GOTMP.360 ]) 0)) > > > > Btw, I think this is a subreg that would be reasonable to handle. > > It's exactly the kind that x86 would like to allow, (subreg:HF (reg:SI > > ..) 0). > > And it is more than reasonable for backends to *not* have to handle such > constructs. Most targets have no use for such surprising things. > > The expander should never create such code in the first place, it is premature > optimisation! At expand time this should be separate statements, first taking > a SI out of a DI, and then converting it to an SF. Fair enough - but extract_bit_field doesn't do this and forcing it to do it regresses things (that was my first preferential treatment...). I realize that the situation around subregs is fragile and there's unlikely going to be a solution that doesn't need fixes in other targets.
