https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51708
--- Comment #4 from Oleg Endo <olegendo at gcc dot gnu.org> ---
There are also constants generated during reload. This is a snippet from bzip
blocksort.c:
.L6:
mov.b @r5+,r1
dt r3
mov.w .L175,r7 // r7 = 1868
extu.b r1,r1
add r15,r7 // r7 = r15 + 1868
shll2 r1
add r7,r1
mov.l @r1,r7
add #1,r7
bf/s .L6
mov.l r7,@r1
...
.L175:
.short 1868
where the constant load can be hoisted, assuming that r0 is not live throughout
the loop:
mov.w .L175,r0 // r0 = 1868
add r15,r0 // r0 = r15 + 1868
.L6:
mov.b @r5+,r1
dt r3
extu.b r1,r1
shll2 r1
add r0,r1
mov.l @r1,r7
add #1,r7
bf/s .L6
mov.l r7,@r1
...
.L175:
.short 1868
Applying addressing mode optimization afterwards can eliminate another insn
from the loop:
mov.w .L175,r0 // r0 = 1868
add r15,r0 // r0 = r15 + 1868
.L6:
mov.b @r5+,r1
dt r3
extu.b r1,r1
shll2 r1
mov.l @(r0,r1),r7
add #1,r7
bf/s .L6
mov.l r7,@(r0,r1)
...
.L175:
.short 1868
If there is no free register available it might be beneficial to insert
pushs/pops around the loop to free up registers for the loop.
