Re: [RFC PATCH 01/43] target/loongarch: Add vector data type vec_t

[gaosong]

在 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