On Mon, Sep 14, 2026 at 11:43 AM Takayuki 'January June' Suwa
<[email protected]> wrote:
> On 2026/09/13 17:03, Max Filippov wrote:
> > On Sat, Sep 12, 2026 at 1:12 PM Takayuki 'January June' Suwa
> > <[email protected]> wrote:
> >>
> >> Cosmetics for readability. Thus no functional changes.
> >
> > But it introduces a regression in gcc.target/xtensa/elim_callee_saved.c,
> > so there's definitely a functional change.
> >
> >> gcc/ChangeLog:
> >>
> >> * config/xtensa/xtensa.cc (xtensa_adjust_reg_alloc_order):
> >> Reformat the "reg_call0_alloc_order" array.
> >> * config/xtensa/xtensa.h (REG_ALLOC_ORDER): Reformat.
> >> ---
> >> gcc/config/xtensa/xtensa.cc | 6 ++----
> >> gcc/config/xtensa/xtensa.h | 6 ++----
> >> 2 files changed, 4 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
> >> index b1daa0f0a99..af1e027f53d 100644
> >> --- a/gcc/config/xtensa/xtensa.cc
> >> +++ b/gcc/config/xtensa/xtensa.cc
> >> @@ -4471,11 +4471,9 @@ xtensa_adjust_reg_alloc_order (void)
> >> REG_ALLOC_ORDER;
> >> static const int reg_call0_alloc_order[FIRST_PSEUDO_REGISTER] =
> >> {
> >> - 9, 10, 11, 7, 6, 5, 4, 3, 2, 8, 0, 12, 13, 14, 15,
> >> - 18,
> >> + 11, 10, 9, 7, 6, 5, 4, 3, 2, 8, 0, 12, 13, 14, 15, 18,
>
> Oops, I accidentally used a snippet from a patch from a different attempt...
That's what I thought.
> Since the order of the first three elements has changed, this certainly counts
> as a functional change. Here is the correct one.
>
> + 9, 10, 11, 7, 6, 5, 4, 3, 2, 8, 0, 12, 13, 14, 15, 18,
Thanks, I'll fix it up.
> BTW, regarding the report that regression occurs in
> gcc.target/xtensa/elim_callee_saved.c,
> on our end:
>
> a. "master" branch
> b."master" with the old and new versions of this patch
> c. "master" with the two preceding patches, and this patch (in both its old
> and new versions)
> d. "master" with the seven patches (including the old and new versions of
> this patch)
>
> In all of the cases mentioned above, the results were all the same, as
> follows:
Must be because I build my tests for the target=xtensa-linux-uclibc
and it generates function calls using PLT, going from
test3:
addi sp, sp, -32
s32i.n a0, sp, 28
s32i.n a12, sp, 24
s32i.n a13, sp, 20
s32i.n a15, sp, 16
mov.n a15, sp
s32i.n a2, a15, 0
l32r a9, .LC0
callx0 a9
mov.n a12, a2
mov.n a13, a3
l32r a9, .LC1
l32i.n a2, a15, 0
callx0 a9
mov.n a10, a2
mov.n a11, a3
l32r a9, .LC2
mov.n a4, a10
mov.n a5, a11
mov.n a2, a12
mov.n a3, a13
callx0 a9
mov.n a10, a2
mov.n a11, a3
l32r a9, .LC3
mov.n a2, a10
mov.n a3, a11
callx0 a9
mov.n a9, a2
mov.n a2, a9
mov.n sp, a15
l32i.n a0, sp, 28
l32i.n a12, sp, 24
l32i.n a13, sp, 20
l32i.n a15, sp, 16
addi sp, sp, 32
ret.n
to
test3:
addi sp, sp, -32
s32i.n a0, sp, 28
s32i.n a12, sp, 24
s32i.n a13, sp, 20
s32i.n a15, sp, 16
mov.n a15, sp
s32i.n a2, a15, 0
l32r a11, .LC0
callx0 a11
mov.n a12, a2
mov.n a13, a3
l32r a11, .LC1
l32i.n a2, a15, 0
callx0 a11
mov.n a6, a2
mov.n a7, a3
l32r a11, .LC2
mov.n a4, a6
mov.n a5, a7
mov.n a2, a12
mov.n a3, a13
callx0 a11
mov.n a10, a2
mov.n a11, a3
mov.n a6, a10
mov.n a7, a11
l32r a11, .LC3
mov.n a2, a6
mov.n a3, a7
callx0 a11
mov.n a11, a2
mov.n a2, a11
mov.n sp, a15
l32i.n a0, sp, 28
l32i.n a12, sp, 24
l32i.n a13, sp, 20
l32i.n a15, sp, 16
addi sp, sp, 32
ret.n
--
Thanks.
-- Max
