https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124021
liu xu <mumuxi_ll at outlook dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mumuxi_ll at outlook dot com
--- Comment #8 from liu xu <mumuxi_ll at outlook dot com> ---
Created attachment 65425
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=65425&action=edit
An RFC patch for auto rvv policy in interrupt handler
Hi, maintainers,
I attached an RFC patch for the stack-usage part of this issue.
With RVV enabled, RISC-V interrupt handlers can get very large stack frames:
the handler body may be auto-vectorized, or a non-leaf interrupt handler may
save call-clobbered V registers for the interrupted context. In the latter
case GCC may emit a VLEN-dependent save/restore sequence for v0-v31, which is
too expensive for small embedded interrupt stacks.
The patch proposes the following policy:
* Disable RVV auto-vectorization for functions with the interrupt attribute.
* In interrupt handlers, save V registers only if they are actually used in
the current function, using df_regs_ever_live_p. Do not save all
call-clobbered V registers just because the handler is non-leaf.
This keeps the existing scalar register handling, but treats RVV specially
because the cost of saving the whole V register file is much higher and
VLEN-dependent.
The patch does not try to infer whether arbitrary callees use RVV. If users
want to call RVV code from interrupt handlers, that probably needs an explicit
attribute/option/policy or manual context handling; otherwise the conservative
answer would be to save the full V context for every non-leaf interrupt
handler, which brings back the stack blow-up.
I added tests for both cases: preventing RVV auto-vectorization in an
interrupt handler, and avoiding the vlenb/vs1r/vl1re save/restore sequence in
a non-leaf interrupt handler that only calls an external function.
This RFC is only about the stack blow-up issue, not the separate vstart
correctness discussion. I would appreciate feedback from the RISC-V
maintainers on whether this policy is acceptable for GCC, or whether this
should instead be controlled by an explicit option or function attribute.
