On Tue, May 12, 2026 at 9:31 AM H.J. Lu <[email protected]> wrote: > > On Tue, May 12, 2026 at 3:11 PM Uros Bizjak <[email protected]> wrote: > > > > On Tue, May 12, 2026 at 9:07 AM H.J. Lu <[email protected]> wrote: > > > > > > On Tue, May 12, 2026 at 3:00 PM Uros Bizjak <[email protected]> wrote: > > > > > > > > On Tue, May 12, 2026 at 8:47 AM H.J. Lu <[email protected]> wrote: > > > > > > > > > > On Tue, May 12, 2026 at 2:39 PM Uros Bizjak <[email protected]> wrote: > > > > > > > > > > > > On Tue, May 12, 2026 at 2:42 AM H.J. Lu <[email protected]> wrote: > > > > > > > > > > > > > > DRAP register is used to restore stack pointer in epilogue for > > > > > > > stack > > > > > > > realignment. In no-callee-saved and preserve_none functions, > > > > > > > although > > > > > > > DRAP register isn't preserved, it must be unchanged between > > > > > > > prologue > > > > > > > and epilogue so that stack pointer can be restored. In > > > > > > > no-callee-saved > > > > > > > and preserve_none functions, mark BX_REG as fixed and use it for > > > > > > > DRAP > > > > > > > register. > > > > > > > > > > > > > > NB: r12-r15 aren't made available as the local general purpose > > > > > > > registers > > > > > > > since it causes: > > > > > > > > > > > > > > FAIL: gcc.target/i386/preserve-none-1.c scan-assembler-not movq > > > > > > > FAIL: gcc.target/i386/preserve-none-30a.c check-function-bodies > > > > > > > entry > > > > > > > FAIL: gcc.target/i386/preserve-none-30b.c check-function-bodies > > > > > > > entry > > > > > > > > > > > > > > which have the same cause as > > > > > > > > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124798 > > > > > > > > > > > > > > gcc/ > > > > > > > > > > > > > > PR target/120870 > > > > > > > * config/i386/i386.cc (X86_NO_CALLEE_DRAP_REG): New. > > > > > > > (ix86_conditional_register_usage): Mark X86_NO_CALLEE_DRAP_REG > > > > > > > as fixed. > > > > > > > (find_drap_reg): Return X86_PRESERVE_NONE_DRAP_REG for > > > > > > > no-callee-saved and preserve_none functions > > > > > > > > > > > > > > gcc/testsuite/ > > > > > > > > > > > > > > PR target/120870 > > > > > > > * gcc.target/i386/pr120870-1.c: New test. > > > > > > > * gcc.target/i386/pr120870-2.c: Likewise. > > > > > > > > > > > > + case TYPE_NO_CALLEE_SAVED_REGISTERS: > > > > > > + case TYPE_PRESERVE_NONE: > > > > > > + /* DRAP register is used to restore stack pointer in epilogue > > > > > > + for stack realignment. Although DRAP register isn't > > > > > > + preserved, it must be unchanged between prologue and > > > > > > + epilogue so that stack pointer can be restored. In > > > > > > + no-callee-saved and preserve_none function, mark BX_REG > > > > > > + as fixed and use it for DRAP register. */ > > > > > > + fixed_regs[X86_NO_CALLEE_DRAP_REG] = 1; > > > > > > > > > > > > Isn't this hammer too big? This will remove RBX even when DRAP is > > > > > > not > > > > > > needed, which I assume is in the majority of cases. > > > > > > > > > > > > > > > > It is only for preserve_none functions where all, but BX, SP, FP, are > > > > > scratch registers. It should be OK. > > > > > > > > But your patch returns X86_NO_CALLEE_DRAP_REG (AKA RBX) from > > > > find_drap_reg. This should signal RA that the register is unavailable. > > > > Why doesn't it? > > > > > > > > > > True, but only for no-callee-saved and preserve_none function: > > > > > > static unsigned int > > > find_drap_reg (void) > > > { > > > if (cfun->machine->call_saved_registers == TYPE_PRESERVE_NONE > > > || (cfun->machine->call_saved_registers > > > == TYPE_NO_CALLEE_SAVED_REGISTERS)) > > > return X86_NO_CALLEE_DRAP_REG; > > > > Yes, but one would expect that the DRAP machinery uses this register > > and that RA automatically avoids it. This is how it works for normal > > functions and I see no reason why preserve_none should be any > > different in this respect. > > > > For normal functions, we use R13, which is a callee-saved register, > for DRAP. But there are no callee-saved registers. If we make RBX > callee-saved with > > call_used_regs[X86_NO_CALLEE_DRAP_REG] = 0; > > I got > > FAIL: gcc.target/i386/pr120870-1.c execution test > FAIL: gcc.target/i386/pr120870-2.c execution test
Let's go back to the Bugzilla PR. I'll do some analysis there. Uros.
