Re: [RISC-V] Reorder the ready queue to avoid extraneous vsetvls

2024-11-04 Thread Jeff Law
On 10/30/24 7:06 PM, Jeff Law wrote: So this patch is a very conservative approach to eliminate more vsetvl instructions. As we know, scheduling can scramble the instruction stream based on a variety of factors and can easily result in an instruction sequence where we ping-pong between dif

Re: [RISC-V] Reorder the ready queue to avoid extraneous vsetvls

2024-10-31 Thread Robin Dapp
> So it's quite conservative, essentially using vector configuration as a > sort key of last resort and only for the highest priority insns in the > ready queue and only when it's going to let us eliminate a vsetvl. On the one hand I wondered if it does make sense to re-use compatible_p from the

Re: [RISC-V] Reorder the ready queue to avoid extraneous vsetvls

2024-10-31 Thread Jeff Law
On 10/31/24 4:30 AM, Robin Dapp wrote: So it's quite conservative, essentially using vector configuration as a sort key of last resort and only for the highest priority insns in the ready queue and only when it's going to let us eliminate a vsetvl. On the one hand I wondered if it does make

[RISC-V] Reorder the ready queue to avoid extraneous vsetvls

2024-10-30 Thread Jeff Law
So this patch is a very conservative approach to eliminate more vsetvl instructions. As we know, scheduling can scramble the instruction stream based on a variety of factors and can easily result in an instruction sequence where we ping-pong between different vector configurations, thus resul