https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81550
--- Comment #6 from Michael Meissner <meissner at gcc dot gnu.org> ---
This is a twisty little passage (all different).
The code is basically trying to test the TARGET_ASM_LOOP_ALIGN_MAX_SKIP target
hook. It carefully aligns the functions to 16 bytes and then wants the normal
loop alignment to 32 bytes.
However, the test for the TARGET_ASM_LOOP_ALIGN_MAX_SKIP target hook (in
rs6000_loop_align_max_skip in rs6000.c) looks at the number of insns generated.
The number of insns generated is now more and the test fails.
Here is the code for 250481 on little endian:
f:
cmpwi 7,6,0
blelr 7
addi 6,6,-1
li 9,0
rldicl 6,6,0,32
addi 10,6,1
mtctr 10
.p2align 5,,31
.L3:
lfdx 0,4,9
lfdx 12,5,9
fadd 0,0,12
stfdx 0,3,9
addi 9,9,8
bdnz .L3
blr
Now the code for 250483 (and current trunk) looks like the following on little
endian:
f:
cmpwi 7,6,0
blelr 7
addi 6,6,-1
addi 9,4,-8
rldic 6,6,3,29
addi 5,5,-8
add 4,4,6
addi 3,3,-8
.p2align 4,,15
.L3:
lfdu 0,8(9)
lfdu 12,8(5)
cmpld 7,9,4
fadd 0,0,12
stfdu 0,8(3)
beqlr 7
lfdu 0,8(9)
lfdu 12,8(5)
cmpld 7,9,4
fadd 0,0,12
stfdu 0,8(3)
bne 7,.L3
blr
There are now 12 insns in the loop, compared to 6 in the previous loop. The
test is emitting the loop alignment if the # of insns in the loop is less than
8.
Big endian generates somewhat different code:
f:
.quad .L.f,.TOC.@tocbase,0
.previous
.type f, @function
.L.f:
cmpwi 7,6,0
blelr 7
addi 6,6,-1
addi 9,4,-8
rldic 6,6,3,29
addi 5,5,-8
add 4,4,6
addi 3,3,-8
.p2align 4,,15
.L3:
addi 9,9,8
addi 5,5,8
lfd 0,0(9)
lfd 12,0(5)
cmpld 7,9,4
addi 3,3,8
fadd 0,0,12
stfd 0,0(3)
beqlr 7
addi 9,9,8
addi 5,5,8
lfd 0,0(9)
lfd 12,0(5)
cmpld 7,9,4
addi 3,3,8
fadd 0,0,12
stfd 0,0(3)
bne 7,.L3
