[Bug target/98309] New: [AVX512] Missing expander for ldexpm3.

["crazylht at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98309

            Bug ID: 98309
           Summary: [AVX512] Missing expander for ldexpm3.
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: crazylht at gmail dot com
                CC: hjl.tools at gmail dot com, wwwhhhyyy333 at gmail dot com
  Target Milestone: ---
            Target: x86_64-*-* i?86-*-*

Cat test.c

#include<math.h>
double
foo (double r, int n)
{
    return ldexp(r, n);
}

gcc -Ofast -mavx512f generate

        jmp     ldexp

But it could be better with

        vcvtsi2sd xmm16, xmm16, edi
        vscalefsd xmm0, xmm0, xmm16
        ret  

Similar for ldexpf, except there could be some precison loss in the conversion
from 32-bit integer to float.
Also the instruction vscalefsd would response for situations
  1.the result overflow or underflow.
  2.the operands is NAN

SCALE(SRC1, SRC2)
{
; Check for denormal operands
TMP_SRC2 := SRC2
TMP_SRC1 := SRC1
IF (SRC2 is denormal AND MXCSR.DAZ) THEN TMP_SRC2=0
IF (SRC1 is denormal AND MXCSR.DAZ) THEN TMP_SRC1=0
/* SRC2 is a 64 bits floating-point value */
DEST[63:0] := TMP_SRC1[63:0] * POW(2, Floor(TMP_SRC2[63:0]))
}

So limit both expander under flag_unsafe_math_optimizations?
Similar for vector version.



cut from Intel SDM
VSCALEFPD—Scale Packed Float64 Values With Float64 Values
-----------------------
Performs a floating-point scale of the packed double-precision floating-point
value in the first source operand by
multiplying it by 2 power of the double-precision floating-point value in
second source operand.
The equation of this operation is given by:
xmm1 := xmm2*2 floor(xmm3) . ------------------------ Here



Floor(xmm3) means maximum integer value ≤ xmm3.
If the result cannot be represented in double precision, then the proper
overflow response (for positive scaling
operand), or the proper underflow response (for negative scaling operand) is
issued. The overflow and underflow
responses are dependent on the rounding mode (for IEEE-compliant rounding), as
well as on other settings in
MXCSR (exception mask bits, FTZ bit), and on the SAE bit.
EVEX encoded version: The first source operand is an XMM register. The second
source operand is an XMM register
or a memory location. The destination operand is an XMM register conditionally
updated with writemask k1.