labath wrote: > > I'm also not very convinced by this "FlowAnalysis" thingy. Is it supposed > > to be a performance optimization (collapsing *&foo to foo) or does it do > > something more? > > FlowAnalysis is also used in subscript operator, to short-circuit getting an > address of an element: `&arr[1]`, which could be a much more common use case.
I see. So, I agree `&a[i]` is likelier than `&*a`. However, I find it hard to imagine how to do that correctly without making too many C-like assumptions about what is an "array". To do this correctly, I think the logic would have to be moved inside the type system, which will be a lot of work for possibly very little gain -- I'm also rather sceptical that something like this will be appreciably faster than just performing the operations in the order prescribed by the expression. I would really want to suggest that you take out this feature and implement dereference/addressof in the simplest possible terms. Once we have all of the pieces in place (*), we can take a look the performance of the code and see if anything needs optimizing. It may turn out that that we can optimize something else so that `[i]` is fast and doesn't need to be optimized by addressof collapsing. Or it may not be a problem at all. I'm sure lldb-eval had its reasons to implement this, but its use case was very different from this, and it wasn't in a position to change lldb to make things faster. We are. (*) My goal is to replace/delete the old "frame var" implementation as soon as possible. Until we do that, every line here is just adding technical debt. Fancy addressof handling is not required to do that. What we need is (simple) implementations of operations that are supported currently. Besides `&` and `*`, that's `.`, `->` and `[]`. https://github.com/llvm/llvm-project/pull/134428 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
