On 12/12/2024 13:47, Torbjorn SVENSSON wrote:


On 2024-12-12 12:02, Richard Earnshaw (lists) wrote:
On 10/11/2024 10:02, Torbjörn SVENSSON wrote:
Ok for trunk, releases/gcc-12, releases/gcc-13 and releases/gcc-14?

--

In version 6-2017-q1-update of the "GNU Arm Embedded Toolchain" build,
there are 2 pop instructions. In version 7-2018-q2-update, the next
version that still have a binary build available on launchpad, there is
only a single pop instruction.
When I try to build vanilla GCC in the same version range, I always end
up with a single pop instruciton.

Since r12-5301-g04520645038, the generated assembler contains one more
registry move, and it's requested in PR103298 to allow it.

Is that reference correct?  Which comment are you referring to if so? That PR is about switch table optimizations.

Now I'm confused. PR103298 is about regressions introduced in r12-5301, right?

Ah, I see.  The pr was referring to two tests:

gcc.target/arm/pr42093.c  which is the jump tables test and

gcc.target/arm/pr43920-2.c which is the test you are working on.

the digits in those two PR numbers are identical, but in a different order. When I looked earlier I hadn't noticed that and followed the link to the wrong PR. My apologies for the confusion that caused.

Now back to the right testcase. This test is horrible: it seems to be trying to test for a specific transformation not being performed by counting the number of return instructions and the number of beq instructions. But neither of these is likely to be very stable given the way the jump threading optimizations work.

I wonder if it would be better here just to scan for the absence of {cmp,mov,orr,and}{eq,ne} in the code (ie for instructions that suggest the use of LOGICAL_OP_SHORT_CIRCUIT).

Increasing the length here is OK, but even that is clearly not guaranteed, hence the skip of that test on fdpic targets, it would be equally good here to just drop that.

R.



Anyway, I was referring to the comment 3 from Richard Biener:

"Again, ARM folks - please allow for the extra reg copy."

So, the size increase is due to an extra reg copy and the reduction in number of pops is that there is only a single pop and I see no obvious reason why there would possibly need to be a 2nd one.

Kind regards,
Torbjörn


R.


gcc/testsuite/ChangeLog:

    PR testsuite/103298
    * gcc.target/arm/pr43920-2.c: Increase allowed text size and
    lower number of expected pop instructions.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svens...@foss.st.com>
---
  gcc/testsuite/gcc.target/arm/pr43920-2.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/pr43920-2.c b/gcc/ testsuite/ gcc.target/arm/pr43920-2.c
index c367d6bc15d..80cc0b7d260 100644
--- a/gcc/testsuite/gcc.target/arm/pr43920-2.c
+++ b/gcc/testsuite/gcc.target/arm/pr43920-2.c
@@ -27,6 +27,6 @@ int getFileStartAndLength (int fd, int *start_, size_t *length_)
        return 0;
  }
-/* { dg-final { scan-assembler-times "pop" 2 } } */
+/* { dg-final { scan-assembler-times "pop" 1 } } */
  /* { dg-final { scan-assembler-times "beq" 3 } } */
-/* { dg-final { object-size text <= 54 { target { ! arm*-*- uclinuxfdpiceabi } } } } */ +/* { dg-final { object-size text <= 56 { target { ! arm*-*- uclinuxfdpiceabi } } } } */



Reply via email to