> -----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