On 2024-12-04 12:41, Richard Earnshaw (lists) wrote:
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.
Pushed as r15-6166-gb7e11b49992. Kind regards, Torbjörn
