[avr-libc-dev] I just noticed OPTIMIZE_SPEED

[George Spelvin]

Perhaps the two different reduction-mod-5 schemes should depend on
OPTIMIZE_SPEED?

Speaking of optimization, there are a significant number of places in
libc/string (and libx/pmstring) where adding one instruction could save
one cycle per byte.

Most of the loops end with

        subi    len_lo, lo8(1)
        sbci    len_hi, hi8(1)
        brcc    .L_loop

The first thing that leaps to mind is that r25:r24 is free (since the
first argument is a pointer which gets moved to X or Z), so adding one
movw to the top would let the loop be counted with sbiw.

But although that saves an instruction, sbiw takes 2 cycles, so we've
gained nothing in the loop and lost one cycle to the movw.


However, there's a second trick, and this one does work.  When the amount
subtracted fits into one byte, you can write:

        subi    len_lo, lo8(1)
        brcc    .L_loop
        sbci    len_hi, 0
        brcc    .L_loop

That's one instruction more, but 255/256 times, the loop will be one
cycle shorter.  (1/256 times, including the last time, the loop will be
one cycle *longer*.)

What's nice about this is that it's easy to define a macro (O_brcc?) which
expands to nothing if OPTIMIZE_SPEED is off.

Anyway, back to what I'm supposed to be working on.  I'm just poking around
the code to familiarize myself with it and noticing low-hanging fruit.