在 2026/11/13 上午11:01, WANG Xuerui 写道:
Hi,
On 11/13/26 10:00, zhaozhou wrote:
For Larch, the lower 64 bits of the 128-bit vector register overlap with
the 64-bit floating-point register, and the lower 128 bits of the 256
bit vector register overlap with the 128-bit vector register. so can be
perform vector width reduction operation on the *vpickve2gr instruction.
1. for [x]vpickve2gr.w, when select the lower 32 bits and the upper
32 bits of the lower 64 bits of the vector register, replace to
movfr2gr.s and movfrh2gr.s.
2. for [x]vpickve2gr.d, when select the lower 64 bits of the vector
register, replace to movfr2gr.d.
3. for xvpickve2gr.w, when select the 3rd or 4th 4-byte data of the
vector register, replace to vpickve2gr.w.
4. for xvpickve2gr.d, when select the 2nd 8-byte data of the vector
register, replace to vpickve2gr.d.
Is there any benefit micro-architecture side, or what's the expected
outcome by doing this? The semantics are equivalent before and after
the change so if not for some performance or maintainability
improvement it probably has no other effect than to obscure the vector
type width in the generated code.
Hi,
This change primarily aims to reduce the latency for extracting vector
elements into general-purpose registers.
On LoongArch, FRs alias the lower bits of VRs/XRs. Experiments on
Loongson 3A5000/3A6000 show that, MOVFR2GR.[SD] has a 1-cycle latency
advantage over VPICKVE2GR.[WD], VPICKVE2GR.[SD] has a 2-cycle latency
advantage over XVPICKVE2GR.[WD].
