https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538
--- Comment #14 from Wilco <wilco at gcc dot gnu.org> ---
(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.
That brings me to another question, why does -mslow-flash-data give an error
when used with Cortex-M0? If the goal was to make things more orthogonal then
surely we should not give an error and allow both options on all M-class cores.
> I believe this is expected: as I wrote in my commit message
> "CASE_VECTOR_PC_RELATIVE is now false with -mpure-code, to avoid generating
> invalid assembly code with differences from symbols from two different
> sections (the difference cannot be computed by the assembler)."
>
> Maybe there's a possibility to tune this to detect cases where we can do
> better?
The best option is to do the same as Cortex-M3: just switch off branch tables
altogether and fall back to compare+branch. That completely avoids loading data
from flash and is always smaller than emitting 32-bit tables.
> > 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
>
> For cortex-m23, I get the same code with and without -mpure-code.
GCC9 emits something different for Cortex-M0 and Cortex-M23 so this was changed
by the patch somehow even when -mpure-code is not enabled. So it is a
regression from what we used to generate.
Similarly I would not expect pure-code to change the decision of whether to
emit immediates as part of the relocation as long as they are within range. The
existing implementation for Cortex-M3 does this correctly.
