[Bug c/115084] New: Missed optimization in division for AVR target, not using __*divmodpsi4

[Bug c/115084] New: Missed optimization in division for AVR target, not using __*divmodpsi4

[kamkaz at windowslive dot com]

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

            Bug ID: 115084
           Summary: Missed optimization in division for AVR target, not
                    using __*divmodpsi4
           Product: gcc
           Version: 14.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kamkaz at windowslive dot com
  Target Milestone: ---

In case the width of both nominator and denominator in integer division are
known to be <=24 bits, in AVR code generation it would be much more efficient
to use psi (24-bit) routines, instead of si (32bit) routines.

avr-gcc -O2

#include <stdint.h>
uint16_t division(uint16_t den) {
    return 7500000u/den;
}

The code generated will use __udivmodsi4, despite __udivmodpsi4 being suitable.

00000000 <division>:
   0:   28 2f           mov     r18, r24
   2:   39 2f           mov     r19, r25
   4:   40 e0           ldi     r20, 0x00       ; 0
   6:   50 e0           ldi     r21, 0x00       ; 0
   8:   60 ee           ldi     r22, 0xE0       ; 224
   a:   70 e7           ldi     r23, 0x70       ; 112
   c:   82 e7           ldi     r24, 0x72       ; 114
   e:   90 e0           ldi     r25, 0x00       ; 0
  10:   03 d0           rcall   .+6             ; 0x18 <__udivmodsi4>
  12:   82 2f           mov     r24, r18
  14:   93 2f           mov     r25, r19
  16:   08 95           ret

Would it be considered to add an optimization, that uses *psi routines in such
cases? I expect it to be worthwhile, since division is rather computation
heavy, It would save ~250 cycles per division where applicable, while the added
division routine occupies 54 bytes.

A workaround is to cast to (__uint24) before dividing, but the __uint24
extension is not widely known, and one would expect such an optimization to
trigger by itself.

[Bug target/115084] Missed optimization in division for AVR target, not using __*divmodpsi4

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target
           Keywords|                            |missed-optimization
           Severity|normal                      |enhancement

[Bug target/115084] Missed optimization in division for AVR target, not using __*divmodpsi4

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
There is another bug dealing with division and truncation that was just filed.
It is a generic (non-avr) issue.

[Bug target/115084] Missed optimization in division for AVR target, not using __*divmodpsi4

[kamkaz at windowslive dot com]

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

--- Comment #2 from Kamil Kaznowski <kamkaz at windowslive dot com> ---
(In reply to Andrew Pinski from comment #1)
> There is another bug dealing with division and truncation that was just
> filed. It is a generic (non-avr) issue.

I assume you mentioned this bug here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115036

It is not quite the same, since here we are dealing with literals. In case of
literals, it is an existing optimization.

#include <stdint.h>

uint16_t functino(uint16_t num) {
    return (7500ULL) / num;
}

This snippet, even compiled with `avr-gcc -O0`, will use __udivmodhi4, 16-bit
routine. It seems that 24-bit routines are simply not considered, unless the
operands are specifically typed __(u)int24.

[Bug target/115084] Missed optimization in division for AVR target, not using __*divmodpsi4

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
I don't see what the avr backend can do about it; it's rather a middle-end
thing.  And the middle-end would have to know that there is a 24-bit integral
mode in the backend and that its division is preferred over 32-bit division...