On Thu, Jan 5, 2023 at 7:35 PM Takayuki 'January June' Suwa
<jjsuwa_sys3...@yahoo.co.jp> wrote:
> On second thought, it cannot be a good idea to split addition/subtraction to
> the stack pointer.
>
> > - 4aaf: b0a192 movi a9, 0x1b0
> > - 4ab2: 1f9a add.n a1, a15, a9
>
> > + 4aaf: 02df12 addmi a1, a15, 0x200
> > + 4ab2: b0c112 addi a1, a1, -80
>
> Because the former is atomic, but the latter is not. (may be interrupted
> between the two add instructions)
Oh, right, there are two issues: one is interruption in the absence of
detailed stack tracking in the DWARF info, which can be fixed by emitting
a separate note for each a1 change, the other is interruption when
a1 is in the parent frame, which can be fixed by always moving a1
down first, e.g. with the following change:
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index 3b8a7bcda371..29cb91fa7de5 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -2539,7 +2539,10 @@ xtensa_split_imm_two_addends (HOST_WIDE_INT
imm, HOST_WIDE_INT v[2])
if (xtensa_simm8 (v1) || xtensa_simm8x256 (v1))
{
- v[0] = v0, v[1] = v1;
+ if (v0 < 0)
+ v[0] = v0, v[1] = v1;
+ else
+ v[0] = v1, v[1] = v0;
return true;
}
Or both can be fixed by using a scratch register in the middle of the
addi/addmi sequence.
> I'll wait for the results of your investigation, but it may be better to
> withdraw the patch.
The issue was in the unwinding code in the libgcc_s.so. I haven't figured
out the exact mechanism, but found that emitting a separate note for each
a1 change fixes it.
--
Thanks.
-- Max
