loic-joly-sonarsource added inline comments.
================
Comment at: clang/lib/ASTMatchers/ASTMatchFinder.cpp:46-49
+enum class MatchDirection {
+ Ancestors,
+ Descendants
+};
----------------
klimek wrote:
> loic-joly-sonarsource wrote:
> > klimek wrote:
> > > Nice find! Why don't we need more states though?
> > > 1. wouldn't hasParent() followed by a hasAncestor() also trigger the
> > > memoization? (if so, we'd need transitive / non-transitive)
> > > 2. can we trigger a directional match and a non-directional
> > > (non-traversal, for example, explicit) match in the same memoization
> > > scope?
> > 1. Yes, I'm going to add it
> > 2. Sorry, I did not understand what you mean...
> >
> Re 2: nevermind, we don't memoize non-transitive matches (other than
> hasParent / hasChild), right?
> In that case, I'm wondering whether the simpler solution is to just not
> memoize hasParent / hasChild - wouldn't that be more in line with the rest of
> the memoization?
If I correctly understand what you mean, you think that memoizing recursive
searches (ancestors/descendants) might not be worth it, and that just memoizing
direct searches (parent, child) would be enough.
I really don't know if it's true or not, and I believe that getting this kind
of data requires a significant benchmarking effort (which code base, which
matchers...). And there might also be other performance-related concerns (for
instance, the value of `MaxMemoizationEntries`, the choice of `std::map` to
store the cache...),
In other words, I think this would go far beyond what this PR is trying to
achieve, which is only correcting a bug.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D80025/new/
https://reviews.llvm.org/D80025
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
