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.
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
optimize_function_for_{size,speed}_p (cfun)
so maybe fast math related stuff is fine, just not the optimization for
speed or size.
Jakub
