> -----Original Message-----
> From: Taylor Simpson
> Sent: Sunday, July 25, 2021 10:02 PM
> To: Richard Henderson <richard.hender...@linaro.org>; qemu-
> de...@nongnu.org
> Cc: phi...@redhat.com; a...@rev.ng; Brian Cain <bc...@quicinc.com>;
> peter.mayd...@linaro.org
> Subject: RE: [PATCH 02/20] Hexagon HVX (target/hexagon) add Hexagon
> Vector eXtensions (HVX) to core
> 
> 
> 
> > -----Original Message-----
> > From: Richard Henderson <richard.hender...@linaro.org>
> > Sent: Sunday, July 25, 2021 8:08 AM
> > To: Taylor Simpson <tsimp...@quicinc.com>; qemu-devel@nongnu.org
> > Cc: phi...@redhat.com; a...@rev.ng; Brian Cain <bc...@quicinc.com>;
> > peter.mayd...@linaro.org
> > Subject: Re: [PATCH 02/20] Hexagon HVX (target/hexagon) add Hexagon
> > Vector eXtensions (HVX) to core
> >


> > > +    /* Temporaries used within instructions */
> > > +    MMVector zero_vector QEMU_ALIGNED(16);
> >
> > You must be doing something wrong to need zero in memory.
> 
> The architecture specifies that if you use a .new in a packet where the vector
> register isn't  defined, it gets zero.  So, the generator produces the 
> following
> for .new references
>     const intptr_t OsN_off =
>         test_bit(OsN_num, ctx->vregs_updated)
>             ? offsetof(CPUHexagonState, future_VRegs[OsN_num])
>             : offsetof(CPUHexagonState, zero_vector);

Correction - the architecture does NOT allow a .new where the vector register 
isn't defined.

This code is being overly cautious, so I'll change it to always return 
future_VRegs and remove zero_vector from CPUHexagonState.

Thanks,
Taylor



Reply via email to