On Fri, Jul 30, 2021 at 4:58 AM Joseph Myers <jos...@codesourcery.com> wrote:
>
> On Tue, 27 Jul 2021, Hongtao Liu via Gcc-patches wrote:
>
> > modified gcc/emit-rtl.c
> > @@ -928,6 +928,10 @@ validate_subreg (machine_mode omode, machine_mode
> > imode,
> > fix them all. */
> > if (omode == word_mode)
> > ;
> > + /* ???Similarly like (subreg:DI (reg:SF), also allow (subreg:SI (reg:HF))
> > + here. Though extract_bit_field is the culprit here, not the backends.
> > */
> > + else if (imode == HFmode && omode == SImode)
> > + ;
>
> You can't reference HFmode by name at all in any target-independent file,
> outside of a #ifdef HAVE_HFmode conditional. It's only defined in
> architecture-specific <arch>-modes.def for those architectures supporting
> that mode, so you'll have an undefined identifier building for other
> targets if you reference it in a generic source file. You have to
> condition things on the logical properties of the mode that are relevant,
> not on the target-specific name (or use a HAVE_HFmode conditional, but
> basing things on logical properties is clearly better where possible).
>
Yes, I didn't notice that, thanks for the explanation.
And I guess the same logic is also applies to BFmode(or other 16bit
float mode) if it existed, so add something like
modified gcc/emit-rtl.c
@@ -928,6 +928,11 @@ validate_subreg (machine_mode omode, machine_mode imode,
fix them all. */
if (omode == word_mode)
;
+ /* ???Similarly like (subreg:DI (reg:SF), also allow (subreg:SI (reg:HF))
+ here. Though extract_bit_field is the culprit here, not the backends. */
+ else if (known_gt (regsize, osize) && known_gt (osize, isize)
+ && FLOAT_MODE_P (imode) && INTEGRAL_MODE_P (omode))
+ ;
> --
> Joseph S. Myers
> jos...@codesourcery.com
--
BR,
Hongtao
