On 22/11/2024 09:37, Torbjörn SVENSSON wrote:
> Changes since v1:
>
> - Rewrote the padding instructions in the macro to instead write to volatile
> memory. This ensures that every expansion of the base macro is exactly 2
> bytes.
>
> If the `GO()` in f3 is removed, the generated assembly would be reduced to:
>
> f3:
> @ args = 0, pretend = 0, frame = 0
> @ frame_needed = 0, uses_anonymous_args = 0
> push {lr}
> cmp r0, #0
> bne .LCB7
> bl .L1 @far jump
> .LCB7:
> movs r2, #1
> ldr r3, .L6
> str r2, [r3]
> ...
> str r2, [r3]
> .L1:
> @ sp needed
> pop {pc}
>
> Would this assembly be as stable as with the `GO()` in f3? If so, would it be
> preferred to generate the simpler assembly in the test?
>
> Ok for trunk as it is or perhaps with the simpler assembly?
>
> --
>
> With the changes in r15-1579-g792f97b44ff, the code used as "padding" in
> the test case is optimized way. Prevent this optimization by forcing a
> read of the volatile memory.
> Also, validate that there is a far jump in the generated assembler.
>
> Without this patch, the generated assembler is reduced to:
> f3:
> cmp r0, #0
> beq .L1
> ldr r4, .L6
> .L1:
> bx lr
> .L7:
> .align 2
> .L6:
> .word g_0_1
>
> With the patch, the generated assembler is:
> f3:
> movs r2, #1
> ldr r3, .L6
> push {lr}
> str r2, [r3]
> cmp r0, #0
> bne .LCB10
> bl .L1 @far jump
> .LCB10:
> b .L7
> .L8:
> .align 2
> .L6:
> .word .LANCHOR0
> .L7:
> str r2, [r3]
> ...
> str r2, [r3]
> .L1:
> pop {pc}
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/thumb1-far-jump-2.c: Write to volatile memmory
> in macro to avoid optimization.
>
> Signed-off-by: Torbjörn SVENSSON <[email protected]>
> ---
> .../gcc.target/arm/thumb1-far-jump-2.c | 95 ++++++++++---------
> 1 file changed, 51 insertions(+), 44 deletions(-)
>
OK.
R.
