在 2022/12/25 上午1:24, Richard Henderson 写道:
On 12/24/22 00:15, Song Gao wrote:
+union fpr_t {
+ uint64_t d;
+ vec_t vec;
+};
+
struct LoongArchTLB {
uint64_t tlb_misc;
/* Fields corresponding to CSR_TLBELO0/1 */
@@ -251,7 +267,7 @@ typedef struct CPUArchState {
uint64_t gpr[32];
uint64_t pc;
- uint64_t fpr[32];
+ fpr_t fpr[32];
I didn't spot it right away, because you didn't add ".d" to the tcg
register allocation,
Oh, my mistake.
but if you use tcg/tcg-op-gvec.h (and you really should), then you
will also have to remove
for (i = 0; i < 32; i++) {
int off = offsetof(CPULoongArchState, fpr[i]);
cpu_fpr[i] = tcg_global_mem_new_i64(cpu_env, off, fregnames[i]);
}
because one cannot modify global_mem variables with gvec.
The manual says "The lower 64 bits of each vector register overlap with
the floating point register of the same number. In other words
When the basic floating-point instruction is executed to update the
floating-point register, the low 64 bits of the corresponding LSX register
are also updated to the same value."
So If we don't use the fpr_t. we should:
1 Update LSX low 64 bits after floating point instruction translation;
2 Update floating-point registers after LSX instruction translation.
Should we do this or have I misunderstood?
I strongly suggest that you introduce wrappers to load/store fpr
values from their env slots. I would name them similarly to
gpr_{src,dst}, gen_set_gpr.
Got it .
Thanks.
Song Gao
