On 2023/01/06 15:26, Max Filippov wrote: > 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. >
Oh, thank you very much for your detailed investigation. I will try to correct what you pointed out ASAP.