https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #28 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Segher Boessenkool from comment #27)
> (In reply to Hongtao.liu from comment #22)
> > > 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).
> >
> > Yes, LRA/reload can handle it correctly, like i tried in #c10.
>
> It is fundamentally wrong to rely on reloading for non-exceptional code.
> If reloading creates good code you are very lucky. And the whole point of
> doing any of this with subregs is to get good code.
I don't have direct evidence to proof LRA/reload is functionally ok to handle
subreg, but x86 have a very heavy use of subreg, also there're comments in
general_operand saying below which makes me believe LRA/reload can handle
subreg right.
if (SCALAR_FLOAT_MODE_P (GET_MODE (op))
/* LRA can use subreg to store a floating point value in an
integer mode. Although the floating point and the
integer modes need the same number of hard registers, the
size of floating point mode can be less than the integer
mode. */
&& ! lra_in_progress
&& paradoxical_subreg_p (op))
return false;
Back to #c10, because I don't know much about the power architecture, the
solution in #c10 that relies on reload to solve this (subreg:SF (reg:DI) 0) is
wrong.
The real problem for rs6000 is SFmode is represented as DFmode in the vector
and floating point registers, and this can't be handled by reload.
validate_subreg disallow (subreg:SF (reg:DI) 0) just so happens that you have
one less special subreg to deal with. there's already
rs6000_emit_move_si_sf_subreg to hanlde (subreg:SF (reg:SI) 0).
