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