[Bug middle-end/114270] New: Integer multiplication on floating point constant with conversion back to integer is not optimized

[Bug middle-end/114270] New: Integer multiplication on floating point constant with conversion back to integer is not optimized

[antoshkka at gmail dot com]

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

            Bug ID: 114270
           Summary: Integer multiplication on floating point constant with
                    conversion back to integer is not optimized
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the following example:

unsigned test(unsigned x) {
    return (unsigned)(x * 0.5);
}

With -O2 GCC generates the code with a fair conversion to fp and
multiplication:

test(unsigned int):
  mov edi, edi
  pxor xmm0, xmm0
  cvtsi2sd xmm0, rdi
  mulsd xmm0, QWORD PTR .LC0[rip]
  cvttsd2si rax, xmm0
  ret

However the multiplication does not overflow and the floating point constant is
a normal number.

A more optimal code should look like the following:

test(unsigned int):
  mov eax, edi
  shr eax
  ret

Probably the optimization could be used for
* any multiplication of integer on positive fp-number less or equal to 1.0
* any division of integer on positive fp-number greater or equal to 1.0
if the result is converted back to integer

[Bug middle-end/114270] Integer multiplication on floating point constant with conversion back to integer is not optimized

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The rules for this to be done are a bit more complex than what is described
here.

1) Significand precision of the floating point type needs to be >= precision of
the integer type
2) the 1/(multiplier) needs to be representable in the integer type
3) (I think this is required) no trapping math is enabled as inexact floating
point exception could happen
4) (maybe?) Significand only has the implicit 1 set.

Note there might be more rules on needed for this to be done and I have not
thought about all of them currently.

[Bug middle-end/114270] Integer multiplication on floating point constant with conversion back to integer is not optimized

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-03-08
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think it makes sense to optimize for 1/power-of-two only.  Whether
an actual integer division instruction we could replace x * FP_CST with
would be faster than int->FP, FP multiply, FP->int is questionable.
But a shift very likely is.

Special-casing just * 0.5 might also an option.

[Bug middle-end/114270] Integer multiplication on floating point constant with conversion back to integer is not optimized

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> The rules for this to be done are a bit more complex than what is described
> here.
> 
> 1) Significand precision of the floating point type needs to be >= precision
> of the integer type

I'd also verify that minimum/maximum of the integer type are exactly
representable in the floating point type, such that even limitations on
exponent don't stand in a way.