Hi Christophe,
I've noticed that your patch caused a regression:
FAIL: gcc.dg/tree-prof/pr77698.c scan-rtl-dump-times alignments
"internal loop alignment added" 1
That's just a testism - it only tests for loop alignment and doesn't
consider the possibility of the loop being jumped into like this:
.L17:
adds r0, r0, #1
b .L27
.L6:
ldr r4, [r2, #12]
adds r0, r0, #4
ldr lr, [r1]
str lr, [r3, r4, lsl #2]
ldr r4, [r2, #12]
ldr lr, [r1]
str lr, [r3, r4, lsl #2]
ldr r4, [r2, #12]
ldr lr, [r1]
str lr, [r3, r4, lsl #2]
.L27:
ldr r4, [r2, #12]
cmp ip, r0
ldr lr, [r1]
str lr, [r3, r4, lsl #2]
bne .L6
pop {r4, pc}
It seems minor changes in scheduling allows blocks to be commoned or not.
The underlying issue is that commoning like this should not be allowed on blocks
with different profile stats - particularly on loops where it inhibits scheduling of
the loop itself.
Cheers,
Wilco