On Sat, Sep 11, 2021 at 5:51 PM Hongtao Liu <crazy...@gmail.com> wrote:
>
> On Sat, Sep 11, 2021 at 4:25 PM Richard Biener via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> >
> > On September 10, 2021 11:27:16 PM GMT+02:00, Segher Boessenkool
> > <seg...@kernel.crashing.org> wrote:
> > >On Fri, Sep 10, 2021 at 08:36:12PM +0200, Richard Biener wrote:
> > >> On September 10, 2021 6:24:50 PM GMT+02:00, Segher Boessenkool
> > >> <seg...@kernel.crashing.org> wrote:
> > >> >Yes, we should not call TRULY_NOOP_TRUNCATION_MODES_P for any random two
> > >> >modes: such a truncation needs to have a meaning at all, for the
> > >> >question to make any sense. Maybe we can add an assert to this macro to
> > >> >root out nonsensical callers?
> > >> >
> > >> >Btw. We have
> > >> >#define TRULY_NOOP_TRUNCATION_MODES_P(MODE1, MODE2) \
> > >> > (targetm.truly_noop_truncation (GET_MODE_PRECISION (MODE1), \
> > >> > GET_MODE_PRECISION (MODE2)))
> > >> >which is not optimal, either: does truncating DFmode to HFmode behave
> > >> >the same as truncating DImode to HImode, on every target? On *any*
> > >> >target, even?!
> > >>
> > >> When is it for any non-scalar integral mode? I suspect this was only
> > >> meaningful for integer modes from the start. On x86 i387 math any float
> > >> mode truncation is noop (with not doing actual truncation to inf).
> > >
> > >And trunc on floating point modes was added later? Yeah, sounds like a
> > >good theory.
> > >
> > >So we should have an assertion in TNTMP that both modes are integral?
> > >(Scalar of course).
> >
> > No, but in the context we are talking about (bitfield extraction) obviously
> > integer truncate is referred to, a FP truncate doesn't make sense here. So
> > either this piece needs to ask for integer modes and then also pun to them
> > or restrict the operation to integer modes. For source int but destination
> > FP there might be other ways to validate whether the target can do this,
> > but TNTMP is not it.
> There is no contradiction between integer truncate and target is
> FLOAT_MODE_P, extv only cares about the bits extraction, look at code
> below, there's convert_extracted_bit_field which is supposed to handle
> non scalar integral mode.
> The key here is the paradoxical subreg (subreg:ext_mode (target)) is
> not necessarily legal, and it is problematic to call gen_lowpart
> directly without guaranteeing this, I still prefer to add a
> validate_subreg(extmode, tmode) condition.
It seems aarch64 use bitfield extraction for
_Float16
foo (int a)
{
union {
int a;
_Float16 b;
}c;
c.a = a;
return c.b;
}
(insn 2 4 3 2 (set (reg/v:SI 93 [ a ])
(reg:SI 0 x0 [ a ]))
"../gcc/intel-innersource/master/gcc/testsuite/gcc.target/i386/float16-5.c":5:1
52 {*movsi_aarch64}
(nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 (set (subreg:DI (reg:HF 94) 0)
(zero_extract:DI (subreg:DI (reg/v:SI 93 [ a ]) 0)
(const_int 16 [0x10])
(const_int 0 [0])))
"../gcc/intel-innersource/master/gcc/testsuite/gcc.target/i386/float16-5.c":11:11
742 {*extzvdi}
(nil))
(insn 7 6 11 2 (set (reg:HF 92 [ <retval> ])
(reg:HF 94))
"../gcc/intel-innersource/master/gcc/testsuite/gcc.target/i386/float16-5.c":11:11
59 {*movhf_aarch64}
(nil))
> >
> > Richard.
> >
> > >
> > >Segher
> >
>
>
> --
> BR,
> Hongtao
--
BR,
Hongtao
