On Thu, Nov 24, 2022 at 4:53 PM Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Thu, Nov 24, 2022 at 09:22:00AM +0800, liuhongt via Gcc-patches wrote:
> > --- a/gcc/config/i386/i386.md
> > +++ b/gcc/config/i386/i386.md
> > @@ -130,6 +130,7 @@ (define_c_enum "unspec" [
> > ;; For AVX/AVX512F support
> > UNSPEC_SCALEF
> > UNSPEC_PCMP
> > + UNSPEC_CVTBFSF
> >
> > ;; Generic math support
> > UNSPEC_IEEE_MIN ; not commutative
> > @@ -4961,6 +4962,31 @@ (define_insn "*extendhf<mode>2"
> > (set_attr "prefix" "evex")
> > (set_attr "mode" "<MODE>")])
> >
> > +(define_expand "extendbfsf2"
> > + [(set (match_operand:SF 0 "register_operand")
> > + (unspec:SF
> > + [(match_operand:BF 1 "register_operand")]
> > + UNSPEC_CVTBFSF))]
> > + "TARGET_SSE2 && !HONOR_NANS (BFmode) && !flag_signaling_nans")
>
> I think if !HONOR_NANS (BFmode), then flag_signaling_nans doesn't matter,
> the former says that no NaNs may appear in a valid program,
> so just testing !HONOR_NANS (BFmode) should be enough.
I'll remove flag_signaling_nans.
>
> What I'm not sure about, my memory is weak, is whether one can
> safely use the fast math related tests in define_expand conditions.
> I vaguely remember init_all_optabs remembers the conditions, for
> changes say in the ISA options optabs are reinited, but not sure if
> that happens for optimization option changes like the fast math related
> options are. So it would be perhaps safer to use just TARGET_SSE2
> as the expand condition and in the C code body do
> if (HONOR_NANS (BFmode) FAIL;
> (similarly for truncsfbf2).
> On the other side brief look at x86 insn-flags.h shows several fast math
> related checks in HAVE_* macros.
> PR92791 I found related to this was actually about
Oh, good to know that, thanks.
> optimize_function_for_{size,speed}_p (cfun)
> so maybe fast math related stuff is fine, just not the optimization for
> speed or size.
I saw many backends(riscv,rs6000,mips,loongarch) already used HONOR_*
stuff in the expander conditions.
>
> Jakub
>
--
BR,
Hongtao
