On 3/19/25 09:39, ltaylorsimp...@gmail.com wrote:
I caution against putting a level of indirection into CPUHexagonState for the
HVX registers. The HVX TCG implementation relies on an offset from the start
of CPUHexagonState to identify the operands. This would be a very significant
rewrite if it's even possible. I don't know if TCG's gvec code generation can
handle random pointers or a level of indirection.
Not yet, it can't, no.
I've been extending it for random pointers because of Arm FEAT_SME2, wherein we have
indirect addressing of matrix slices. So we wind up with a pointer like
&env->zarray + (env->xregs[reg] + offset) % size
If the behavior is undefined, we can avoid the copies. Then we just need some
bookkeeping to check if multiple threads try to claim the same context (if that
behavior is defined). If copies are needed, we could keep the hardware
contexts as shared a shared resource. Another alternative would be to track
the current owner of a context and copy from the previous owner's {VQ}Regs to
the new owners {VQ}Regs.
Depending on how you answer these questions, I could split out the TCG work.
But in the short term, copying context data might well be easier.
r~
