https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #26 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #24) > > 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...). Yes, it needs to be fixed one step at a time. Since subreg does six or seven different things anything with it is a tangled mess, and we cannot move things forward unless we untangle things. That is also how we can do this without regressing things left and right: first we should *only* open things up, make things more manageable, easier to change. This will take time, I am not under the illusion that it can be finished in time for GCC 12. But if we do not start now, it will not be done in GCC 13 either. > 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. Right. But if we tackle one thing at a time, and make things *simpler*, and add testcases -- then it should not be all that hard in the end. Painful, yes, I don't think we can avoid that :-)
