[Bug target/102309] New: thumb2-replicated-constant2.c fails on cortex-m7

[Bug target/102309] New: thumb2-replicated-constant2.c fails on cortex-m7

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102309

            Bug ID: 102309
           Summary: thumb2-replicated-constant2.c fails on cortex-m7
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

I've noticed that gcc.target/arm/thumb2-replicated-constant2.c fails when
targeting cortex-m7.

For instance for the first fonction, for cortex-m4 we generate:
foo1:
        add     r0, r0, #-33489408                                              
        adds    r0, r0, #1                                                      
        bx      lr

for cortex-m7, we generate:
foo1:
        mov     r3, r0
        ldr     r0, .L3
        add     r0, r0, r3
        bx      lr
.L4:
        .align  2
.L3:
        .word   -33489407

This is because arm_cortex_m7_tune has 0 in constant_limit, while the generic
arm_v7m_tune has 1.

This setting has been in place since r5-4680 in 2014, see
https://gcc.gnu.org/pipermail/gcc-patches/2014-November/403718.html

Since it was the result of benchmarking, I guess this is a feature, not a bug?
Is this really faster?

[Bug target/102309] thumb2-replicated-constant2.c fails on cortex-m7

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102309

--- Comment #1 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
A constant limit of zero doesn't make sense to me, that would theoretically
push everything into the literal pool regardless of the number of insns needed.