[Bug fortran/108878] New: Mis-optimization with splitting floating point into a significand and exponent.

[Bug fortran/108878] New: Mis-optimization with splitting floating point into a significand and exponent.

[kargl at gcc dot gnu.org]

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

            Bug ID: 108878
           Summary: Mis-optimization with splitting floating point into a
                    significand and exponent.
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Fortran does not have an equivalent to C's frexp(), which splits a floating
point value into its significand and exponent.  Fortran has exponent() and
fraction() to grab the exponent and significand, respectively.  Consider,

% cat a.f90
subroutine foo(x, f, m)
   real, intent(in) :: x
   real, intent(out) :: f
   integer, intent(out) :: m
   m = exponent(x)
   f = fraction(x)
end subroutine

% gfortran -Ofast -fdump-tree-optimized -S a.f90
% more a.f90.254t.optimized
...
  <bb 2> [local count: 1073741824]:
  _5 = *x_4(D);
  __builtin_frexpf (_5, &D.4261);
  _1 = D.4261;
  *m_7(D) = _1;
  D.4261 ={v} {CLOBBER(eol)};
  _2 = __builtin_frexpf (_5, &D.4263);
  *f_11(D) = _2;
  D.4263 ={v} {CLOBBER(eol)};
  return;

As can be seen, __builtin_frexpf() is called twice.  The generated assembly
also shows two calls to frexpf().


% more a.s
...
        .cfi_offset 3, -32
        movq    %rsi, %rbx
        subq    $32, %rsp
        movss   (%rdi), %xmm1
        leaq    -20(%rbp), %rdi
        movaps  %xmm1, %xmm0
        movss   %xmm1, -36(%rbp)
        call    frexpf
        movl    -20(%rbp), %eax
        movss   -36(%rbp), %xmm1
        leaq    -20(%rbp), %rdi
        movl    %eax, (%r12)
        movaps  %xmm1, %xmm0
        call    frexpf
        movss   %xmm0, (%rbx)
        addq    $32, %rsp
        popq    %rbx
        popq    %r12
        popq    %rbp
        .cfi_def_cfa 7, 8
...

[Bug fortran/108878] Mis-optimization with splitting floating point into a significand and exponent.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-02-21
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
           Priority|P3                          |P4

[Bug middle-end/108878] Mis-optimization with splitting floating point into a significand and exponent.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |middle-end
           Severity|normal                      |enhancement
           Keywords|                            |missed-optimization

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I thought we had another one about a missing frexpf case (besides PR 98176).

[Bug middle-end/108878] Mis-optimization with splitting floating point into a significand and exponent.

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So the right way of fixing this is to have a builtin versions of "frexp" which
return a complex type and that is pure for -fno-math-errno and such. And gets
expanded to frexp correctly.

[Bug middle-end/108878] Mis-optimization with splitting floating point into a significand and exponent.

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> So the right way of fixing this is to have a builtin versions of "frexp"
> which return a complex type and that is pure for -fno-math-errno and such.
> And gets expanded to frexp correctly.

Similarly how sincos gets turned into __builtin_cexpi .

[Bug middle-end/108878] Mis-optimization with splitting floating point into a significand and exponent.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Feb 21, 2023 at 09:49:38PM +0000, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
> 
> --- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> So the right way of fixing this is to have a builtin versions of "frexp" which
> return a complex type and that is pure for -fno-math-errno and such. And gets
> expanded to frexp correctly.
> 

A complex type seems out-of-place as the exponent() returns
an integer and fraction() a real.  __builtin_frexp() already
returns the info.  I was hoping that he following:

  _5 = *x_4(D);
  __builtin_frexpf (_5, &D.4261);
  _1 = D.4261;
  *m_7(D) = _1;
  D.4261 ={v} {CLOBBER(eol)};
  _2 = __builtin_frexpf (_5, &D.4263);
  *f_11(D) = _2;
  D.4263 ={v} {CLOBBER(eol)};

could be transformed into

  <bb 2> [local count: 1073741824]:
  _5 = *x_4(D);
  _2 = __builtin_frexpf (_5, &D.4263);
  _1 = D.4263;
  *m_7(D) = _1;
  *f_11(D) = _2;
  D.4263 ={v} {CLOBBER(eol)};

[Bug middle-end/108878] Mis-optimization with splitting floating point into a significand and exponent.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Could be an internal function returning a structure containing the floating
point member and integral member.  But still, it needs to be something that can
act as a pure function.  Though, I bet complex is really better.  We could use
VIEW_CONVERT_EXPR on the IMAGPART_EXPR to get the int part.

[Bug middle-end/108878] Mis-optimization with splitting floating point into a significand and exponent.

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
For the specific testcase I also wonder if the Fortran frontend optimization
pass can somehow unify these?

But yes, to be able to optimize these kind of library functions we need an
internal representation that doesn't involve memory.  An internal function
with a _Complex integer return value should do.  I think it's better to
V_C_E from integer to float, and to truncate from long int to int for
frexp[l].  That avoids oddities with XFmode but we have to choose
int128_t there which makes it difficult for 32bit x86 abd frexpl.

In the end we'd like to support multiple return values in a nicer way,
the least invasive might be using a structure type specially marked as
register type that we'd write into SSA and never support partially
altering (or even constructing by sth else than calls).  But then a
'pair' of SSA names via a special type kind that just does composition
but no layouting would be a nicer way.

[Bug middle-end/108878] Mis-optimization with splitting floating point into a significand and exponent.

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, it _might_ be possible to special case such functions in VN as well,
but to be not too intrusive it would happen at elimination time where we
also remove redundant stores so secondary effects of the fact that
D.4263 and D.4261 are equal would not be catched.  Getting that is more
difficult.

[Bug middle-end/108878] Mis-optimization with splitting floating point into a significand and exponent.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Feb 22, 2023 at 08:48:07AM +0000, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
> 
> --- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
> For the specific testcase I also wonder if the Fortran frontend optimization
> pass can somehow unify these?

This might be possible.  Thomas knows the frontend pass better
than I.  Thomas, do you think it would be possible to replace

    m = exponent(x)
    f = fraction(x)

with a single function/subroutine call?