https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 8 Sep 2021, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154 > > --- Comment #17 from Segher Boessenkool <segher at gcc dot gnu.org> --- > (In reply to Hongtao.liu from comment #15) > > as discussed in > > https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578437.html, allow > > specific float-int subreg seems weird. > > Indiscriminately allowing all of them is a bad idea. No machine (that has > more than just integer hardware) can actually use those, resulting in ICEs > (like here) or inefficient code generated by reload, or a mix, or worse. > > > And when i look the pattern, it also seems to be strange to disallow subreg > > in operands[1], IMHO things like TARGET_ALLOW_SF_SUBREG should be done in > > TARGET_CAN_CHANGE_MODE_CLASS, so reload/lra will do the right thing. > > No. We usually have this in the predicates. But there simply is no even > remotely efficient way to do such moves, so we should not pretend there is. So I wonder if it makes sense to allow lowpart subregs of any mode when the inner mode is integer. There's already /* ??? Similarly, e.g. with (subreg:DF (reg:TI)). Though store_bit_field is the culprit here, and not the backends. */ else if (known_ge (osize, regsize) && known_ge (isize, osize)) ; where regsize is REGMODE_NATURAL_SIZE (imode) but with a HFmode subreg of DImode the known_ge (osize, regsize) doesn't apply (I wonder what that condition is about - it looks rather arbitrary). The above allowance also doesn't restrict the subreg offset in any way.
