On 3/19/2025 11:58 AM, Richard Henderson wrote:
On 3/19/25 09:39, [email protected] 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.
I've removed HVX context management from this series and will propose it
in a future one. Indeed the behavior is undefined when multiple
hardware threads try to access the same context. If the TCG changes for
indirection show up at some point (or have already shown up) that would
be great for us to take advantage of. But the copies seem adequate for now.
r~
