Fix profile updating in ifcombine
Jan Hubicka
hubicka@ucw.cz
Mon Feb 6 15:26:00 GMT 2017
>
> After this patch (r245151), I've noticed regressions on aarch64:
> gcc.target/aarch64/test_frame_1.c scan-assembler-times ldr\tx30,
> \\[sp\\], [0-9]+ 2
> gcc.target/aarch64/test_frame_2.c scan-assembler-times ldp\tx19,
> x30, \\[sp\\], [0-9]+ 1
> gcc.target/aarch64/test_frame_4.c scan-assembler-times ldp\tx19,
> x30, \\[sp\\], [0-9]+ 1
> gcc.target/aarch64/test_frame_6.c scan-assembler-times ldr\tx30, \\[sp\\] 2
> gcc.target/aarch64/test_frame_7.c scan-assembler-times ldp\tx19,
> x30, \\[sp\\] 1
>
> now FAIL.
>
> For instance in test_frame_1.c, we used to generate:
> ccmp w2, w1, 0, eq
> bne .L6
> ldrb w0, [sp, 123]
> ldrb w1, [sp, 124]
> cmp w0, 99
> ccmp w1, w0, 0, eq
> cset w0, eq
> .L6:
> ldr x30, [sp], 224
> ret
>
> and now:
> ccmp w2, w1, 0, eq
> beq .L11
> ldr x30, [sp], 224
> ret
> .p2align 3
> .L11:
> ldrb w0, [sp, 123]
> ldrb w1, [sp, 124]
> cmp w0, 99
> ldr x30, [sp], 224
> ccmp w1, w0, 0, eq
> cset w0, eq
> ret
>
> which is 2 instructions more, as the control flow is less efficient.
>
> Do we want to just update the tests (increasing the number of expected
> str/ldr/stp/ldp to match the new code generation), or do we
> consider this a regression caused by this patch?
I think it is not a regression, just the testcase if fragile and depends on outcome
of ifcombine. It seems it was updated several time in the past. I am not quite
sure what the test is testing, but probably just updating the testcase and/or
disabling the ifconvert pass for it is the right answer.
Honza
More information about the Gcc-patches
mailing list