[Bug target/51708] [SH] CSE constants after combine/split

[olegendo at gcc dot gnu.org via Gcc-bugs]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #5 from Oleg Endo  ---
The latest patch https://gcc.gnu.org/bugzilla/attachment.cgi?id=55543 by Alex
in PR 54089 inserts some additional passes in order to hoist constant loads for
shift operations out of loops.  Perhaps that would fix this issue, too.

[Bug target/51708] [SH] CSE constants after combine/split

[olegendo at gcc dot gnu.org]

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.