omjavaid added a comment. > I don't know about expensive literally but I did wonder if we could rely on > the NativeRegisterContextLinux_arm64 buffers not being modified while the > expression runs. Then do what I think you mean which is just flush them all > to the process. > > I'll need to work out exactly when SaveAll/WriteAll is and can be called. > Part of me wonders why we even have such methods if you could just flush the > existing buffers, but it wouldn't be the first time we've duplicated things.
I guess it looks like a lucrative solution but process/registers state between two consecutive stops can not be determined hence we are stuck with old fashioned way of save/restore. > At minimum the SVE registers and the ZA header and tpidr2. So ~ (45*16) + 16 > + 16 + 8. If ZA is on then you've got another 16*16 on top of that. > > But to be clear, the amount of data is not the issue this change aims to > address, it's purely the ordering of the restoration. Agreed, I am just curious if we can save some cycles by avoiding copying first from source to cache and then writing to registers. Specially when we are going to invalidate the cache anyway after the write. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D156687/new/ https://reviews.llvm.org/D156687 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
