[Lldb-commits] [PATCH] D96458: [LLDB] Add support for Arm64/Linux dynamic register sets

[Muhammad Omair Javaid via Phabricator via lldb-commits]

omjavaid added a comment.

In D96458#2625554 <https://reviews.llvm.org/D96458#2625554>, @omjavaid wrote:

> In D96458#2624962 <https://reviews.llvm.org/D96458#2624962>, @labath wrote:
>
>> Thanks. This looks much better, but there is still one thing which bugs me about the register info constructor. Currently, there are three paths through that constructor:
>>
>> 1. when we don't have any fancy registers (this is the original one)
>> 2. when we have just SVE (added with the sve support)
>> 3. when we have pauth et al. (added now)
>>
>> Do we need all three of them? Is there anything which makes SVE special that it deserves its own register info array? Could it be just another "dynamic" register set like the other features? (If that's true, I might consider also removing the first code path, making it just a special case of an empty set of dynamic features.)
>>
>> I also have some inline comments, but there are just simple stylistic issues, I hope.
>
> I agree with your about SVE being dynamic I just didn't go for the change because I was being a little conservative about changing existing functionality. But I think If we look at the changes now making SVE dynamic seems right thing to do. Let me make the change and update this rev.

@labath 
I forgot to mention but recalled after looking at the code that the major problem/hurdle is g_contained_* and *_invalidates reg list. In case of SVE V, D and S registers are contained by Z register and therefore we will have to update their contained and value reg list accordingly. Only registers declaration which we can skip out of the SVE's register info array are the GPRs X and W. Larger the register set more complicated handling of its dynamic register set will be.
We have three options here:

1. Keep current state and use separate register info array in case of SVE (Simple solution)
2. We skip the GPRs out of SVE's register info array and declare all vector registers in SVE's register info array using appropriate contained and invalidate register lists.

Looking at this now I dont see this much of advantage just for the sake of pulling out GPR declaration from SVE register info array. What do you think?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96458/new/

https://reviews.llvm.org/D96458