On Mon, Jul 29, 2024 at 11:20 AM Jeff Law <jeffreya...@gmail.com> wrote: > > > > On 7/29/24 6:18 AM, Raphael Zinsly wrote: > > On Fri, Jul 26, 2024 at 6:48 PM Jeff Law <jeffreya...@gmail.com> wrote: > >> > >> > >> > >> On 7/24/24 12:00 PM, Raphael Moreira Zinsly wrote: > >>> Adds basic support to vector stack-clash protection using a loop to do > >>> the probing and stack adjustments. > >>> > >>> gcc/ChangeLog: > >>> * config/riscv/riscv.cc > >>> (riscv_allocate_and_probe_stack_loop): New function. > >>> (riscv_v_adjust_scalable_frame): Add stack-clash protection > >>> support. > >>> (riscv_allocate_and_probe_stack_space): Move the probe loop > >>> implementation to riscv_allocate_and_probe_stack_loop. > >>> * config/riscv/riscv.h: Define RISCV_STACK_CLASH_VECTOR_CFA_REGNUM. > >>> > >>> gcc/testsuite/ChangeLog: > >>> * gcc.target/riscv/stack-check-cfa-3.c: New test. > >>> * gcc.target/riscv/stack-check-prologue-16.c: New test. > >>> * gcc.target/riscv/struct_vect_24.c: New test. > >> So my only worry here is using another scratch register in the prologue > >> code instead of using one of the preexisting prologue scratch registers. > >> Is there a reasonable way to use PROLOGUE_TEMP or PROLOGUE_TEMP2 here? > > > > These are the preexisting prologue scratch registers: PROLOGUE_TEMP is > > t0 and PROLOGUE_TEMP2 is t1. > > > >> Otherwise this looks good as well. So let's get closure on that > >> question and we can move forward after that. > Right. And so my question is can we use PROLOGUE_TEMP or PROLOGUE_TEMP2 > rather than defining another temporary for the prologue?
We are only using these two and we do not need to use another temporary. Do you mean stop using riscv_force_temporary? If so, yes, we can change it to riscv_emit_move. > It may not seem all that important, but the more distinct hardware > register we use this way, the more likely we are to run into problems > with -fcall-saved-<reg> options. Right now I suspect both the risc-v > and aarch64 ports are broken WRT the -fcall-saved-<reg> option. We > shouldn't make it worse if we can avoid it. > > jeff Thanks, -- Raphael Moreira Zinsly
