[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
Fri Apr 17 10:23:59 GMT 2020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538
--- Comment #16 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #15)
> (In reply to Wilco from comment #14)
> > (In reply to Christophe Lyon from comment #11)
> > > (In reply to Wilco from comment #10)
> >
> > > Right, but the code is functional.
> >
> > It doesn't avoid the literal load from flash which is exactly what pure-code
> > and slow-flash-data is all about.
>
> For f1 on M0, I can see:
> .section .rodata.cst4,"aM",%progbits,4
> .align 2
> .LC0:
> .word .LANCHOR0
> .section .text,"0x20000006",%progbits
> [...]
> f1:
> 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 r3, [r3] @ 6 [c=10 l=2] *thumb1_movsi_insn/8
> ldr r0, [r3] @ 7 [c=10 l=2] *thumb1_movsi_insn/8
> bx lr
> [...]
> .bss
> .align 2
> .set .LANCHOR0,. + 0
> .type x, %object
> .size x, 4
> x:
> .space 4
>
> So the 1st load is from .rodata.cst4 and the 2nd load is from bss, both of
> which do not have the purecode bit set (unlike .text). Isn't that OK?
No, it will create a lot of complaints and support queries due to the obvious
regressions. It goes against the definition of pure-code and slow-flash-data
which is to remove the literal loads. And given the sequence is already
inefficient, we should do everything to remove the indirection which increases
the codesize overhead by 75%...
Another aspect that needs to be checked is that GCC correctly spills addresses
and complex constants instead of rematerializing them. This is basic minimal
quality that one expects for a feature like this.
More information about the Gcc-bugs
mailing list