labath added a comment. I'm not sure I agree with that. Given the ever-growing number of registers (which are likely going to all end up in the "xstate" block), I think it is important to be able to add some structure to the list of registers. Also, having the ability to group registers which can come or go together will probably make it easier to implement the "disappearance" of unsupported registers. Given how xstate works, I think the individual register sets are a better match (more or less) for the individual "features" of that state rather than for the block as a whole.
I don't think it should be that hard to come up with a solution that allows caching at xstate level, but still keeps finer-grained groups. One way, which does not require the explicit concept of a "second order group", is to allow the cache reading/writing function to mark multiple sets as read/written. In this world it wouldn't be the generic code which manages the state of each set, but the individual writing function instead. This way the reading/writing function could mark any number of registers sets as read/written. The generic code could just assert that the set that it cares about has been processed correctly. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90034/new/ https://reviews.llvm.org/D90034 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
