[Bug target/94538] [10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data

["wilco at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #10 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #8)
> > Adding Christophe. I'm thinking the best approach right now is to revert
> > given -mpure-code doesn't work at all on Thumb-1 targets - it still emits
> > literal pools, switch tables etc. That's not pure code!
> 
> Do you have testcases that show these failures?
> 
> I did check some of the problematic testcases in the GCC testsuite when I
> committed that patch. Did I miss some of them?
> 
> Can you point me to offending testcases and compiler options so that I can
> reproduce them?

For example:

int x;
int f1 (void) { return x; }

with eg. -O2 -mcpu=cortex-m0 -mpure-code I get:

        movs    r3, #:upper8_15:#.LC1
        lsls    r3, #8
        adds    r3, #:upper0_7:#.LC1
        lsls    r3, #8
        adds    r3, #:lower8_15:#.LC1
        lsls    r3, #8
        adds    r3, #:lower0_7:#.LC1
        @ sp needed
        ldr     r3, [r3]
        ldr     r0, [r3, #40]
        bx      lr

That's an extra indirection through a literal... There should only be one ldr
to read x.

Big switch tables are produced for any Thumb-1 core, however I would expect
Cortex-m0/m23 versions to look almost identical to the Cortex-m3 one, and use a
sequence of comparisons instead of tables.

int f2 (int x, int y)
{
  switch (x)
  {
    case 0: return y + 0;
    case 1: return y + 1;
    case 2: return y + 2;
    case 3: return y + 3;
    case 4: return y + 4;
    case 5: return y + 5;
  }
  return y;
}

Immediate generation for common cases seems to be screwed up:

int f3 (void) { return 0x11000000; }

-O2 -mcpu=cortex-m0 -mpure-code:

        movs    r0, #17
        lsls    r0, r0, #8
        lsls    r0, r0, #8
        lsls    r0, r0, #8
        bx      lr

This also regressed Cortex-m23 which previously generated:

        movs    r0, #136
        lsls    r0, r0, #21
        bx      lr

Similar regressions happen with other immediates:

int f3 (void) { return 0x12345678; }

-O2 -mcpu=cortex-m23 -mpure-code:

        movs    r0, #86
        lsls    r0, r0, #8
        adds    r0, r0, #120
        movt    r0, 4660
        bx      lr

Previously it was:

        movw    r0, #22136
        movt    r0, 4660
        bx      lr

Also relocations with a small offset should be handled within the relocation.
I'd expect this to never generate an extra addition, let alone an extra literal
pool entry:

int arr[10];
int *f4 (void) { return &arr[1]; }

-O2 -mcpu=cortex-m3 -mpure-code generates the expected:

        movw    r0, #:lower16:.LANCHOR0+4
        movt    r0, #:upper16:.LANCHOR0+4
        bx      lr

-O2 -mcpu=cortex-m23 -mpure-code generates this:

        movw    r0, #:lower16:.LANCHOR0
        movt    r0, #:upper16:.LANCHOR0
        adds    r0, r0, #4
        bx      lr

And cortex-m0 again inserts an extra literal load:

        movs    r3, #:upper8_15:#.LC0
        lsls    r3, #8
        adds    r3, #:upper0_7:#.LC0
        lsls    r3, #8
        adds    r3, #:lower8_15:#.LC0
        lsls    r3, #8
        adds    r3, #:lower0_7:#.LC0
        ldr     r0, [r3]
        adds    r0, r0, #4
        bx      lr