omjavaid wrote: > @omjavaid, I apologize for the delayed response. Thanks for looking into this! > > > **1)** Description and commit message may require a rewrite. I had to read > > till the last paragraph to figure out that VL is fixed for process > > lifetime. Also streaming mode is an SME thing, mixing it in here makes it > > confusing whether dynamic switching between SVE and SME and dynamic > > register size change is supported or not. > > Microsoft hasn't released a Windows SDK with streaming SVE support yet; so, > streaming-mode register access is still unsupported. However, once streaming > SVE is available, a thread may move between streaming and non-streaming > modes, which could change the vector length even if it only alternates > between the two possible values: the non-streaming and streaming SVE vector > lengths. As a result, the register context layout may need to change when > streaming SVE support is introduced. Nevertheless, I agree that this could > create unnecessary confusion. So, streaming SVE will be handled separately > when the support becomes available. > > > **2)** ConfigureRegisterContext runs on every stop via DoStop -> > > InvalidateAllRegisters and does a full GetThreadContext with XSTATE for > > every thread. Can we do something about it? Also the comment says "in case > > there is any change in the configuration" which contradicts the > > description, VL cant change. > > The latest revision no longer suggests dynamic vector length switching. It > separates SVE layout configuration from stop-time value invalidation. > Moreover, SVE layout configuration no longer caches thread contexts. The > non-streaming SVE vector length is cached in _m_sve_vl_ after the SVE header > has been read and parsed for the first time, and _vg_ is served from that > cache if available. Splitting GPR/FPR-only caching from SVE caching is left > as a follow-up. > > > **4)** We need a way to test this without hardware, something like > > https://lldb.llvm.org/resources/qemu-testing.html but for windows. > > **5)** Current test only runs at VL=128 where Z access just falls back to > > FPR read/write so the new interleaving code never actually runs. Can you do > > a run on a QEMU windows arm64 guest with SVE VL > 128 and share results? > > Best if you give add test instructions using QEMU and may be if I find time > > can try it own my own. > > Agreed, testing this with QEMU especially with VL > 128 so that the > Z-register high-byte interleaving path is covered would be very valuable (the > currently available hardware only exposes VL=128). Would it be alright if we > address this in a follow-up change? I’ve documented the current limitation > and updated the test to derive register sizes from vg rather than assuming > that vg is 128 bits. That should allow the test to run correctly on a > wider-VL configuration once one is available. > If today's hardware is restrictred to 128 bits then it is essentially NEON FP-SIMD wearing a SVE cloak. If that is the case it strengthens the case for improving this patch before landing it upstream.
> > **7)** Too many #if PF_ARM_SVE_INSTRUCTIONS_AVAILABLE, even inside function > > signatures and if bodies, hard to follow the control flow. We had the same > > problem on Linux and solved it with LinuxPTraceDefines_arm64sve.h. > > I agree, the conditional structure is indeed noisy. However, a Windows > equivalent of _LinuxPTraceDefines_arm64sve.h_ may be simpler to tackle after > we’ve landed a minimum viable product. What do you think? Does Windows expose SVE registers in Minidumps? if yes how and if we analyze a minidump containing SVE registers while running on linux how SVE will be able to manage that? IMO, SVE support on Winodws is half baked still evolving. I dont see any urgency in landing these changes as there is no real user of these changes unless we provide viable hardware software combination or virtual environment that actually can be used to test this code. https://github.com/llvm/llvm-project/pull/205906 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
