sped-up functions from lib1funcs.S: what about using more instructions and/or stack?

Wolfgang Hospital <[email protected]> Wed, 15 May 2024 08:47:24 +0200
Newsgroups	gmane.comp.hardware.avr.gcc
Message-ID	<[email protected]>
This is a multi-part message in MIME format.
--------------7FN5y4O00XGxiEnhvHHZM0hT
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

  Dear all,

G-J Lay has been kind enough to turn my whine about __udivmodqi4 into a 
bug report and handle that; I tried to follow suit reporting further 
strict improvements (NO resource used more, at least one used less).
While I think bug keyword "missed-optimization" is for missing 
opportunities during compilation, I have no problem regarding strictly 
sub-optimal library code as a missed optimization.

But what about speed improvements that take more instructions and/or 
stack, or are slower for some argument values? Starting with a same size 
__mulqi3 faster for all multipliers but zero, for which it is slower, or 
a __mulhi3 with worst case about twice as fast, but 3 instructions 
longer than the current code (both pointless for cores with mul, 
obviously). Or division routines: a faster one that is no larger 
"without movw", but uses one more return address on stack; one that is 2 
instructions smaller, a wee bit faster on average, but slower worst 
case; one that's about 14 cycles faster, but 1 instruction longer?

How important is arithmetic for longer operands?

regards

W. Hospital

-- 
Wolfgang Hospital

--------------7FN5y4O00XGxiEnhvHHZM0hT
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><font face="tt"> Dear all,</font></p>
    <p><font face="tt">G-J Lay has been kind enough to turn my whine
        about </font><font face="tt">__udivmodqi4 into a bug report and
        handle that; I tried to follow suit reporting further strict
        improvements (NO resource used more, at least one used less).<br>
        While I think bug keyword "missed-optimization" is for missing
        opportunities during compilation, I have no problem regarding
        strictly sub-optimal library code as a </font><font face="tt">missed
        optimization</font><font face="tt">.<br>
      </font></p>
    <p><font face="tt">But what about speed improvements that take more
        instructions and/or stack, or are slower for some argument
        values? Starting with a same size __mulqi3 faster for all
        multipliers but zero, for which it is slower, or a __mulhi3 with
        worst case about twice as fast, but 3 instructions longer than
        the current code (both pointless for cores with mul, </font><font
        face="tt">obviously). Or division routines: a faster one that is
        no larger "without movw", but uses one more return address on
        stack; one that is 2 instructions smaller, a wee bit faster on
        average, but slower worst case; one that's about 14 cycles
        faster, but 1 instruction longer?</font></p>
    <p><font face="tt">How important is arithmetic for longer operands?</font><br>
      <font face="tt"> <br>
        regards<br>
        <br>
        W. Hospital<br>
      </font></p>
    <pre class="moz-signature" cols="72">-- 
Wolfgang Hospital</pre>
  </body>
</html>

--------------7FN5y4O00XGxiEnhvHHZM0hT--