iains added a comment. In D124287#3479484 <https://reviews.llvm.org/D124287#3479484>, @jansvoboda11 wrote:
> In D124287#3476040 <https://reviews.llvm.org/D124287#3476040>, @vsapsai wrote: > >> In D124287#3474369 <https://reviews.llvm.org/D124287#3474369>, @jansvoboda11 >> wrote: >> >>> This sounds reasonable to me. What use-cases does >>> `ASTStructuralEquivalence` fit better than ODR hashes? >> >> I think the biggest advantage of `ASTStructuralEquivalence` is that it >> doesn't affect memory consumption by Decls. But it makes repeated >> comparisons more expensive. >> >> Another `ASTStructuralEquivalence` advantage is that it's easier to add new >> checks. For example, comparing ivars is pretty trivial with >> `ASTStructuralEquivalence` but with ODR hash we need to handle that ivar >> types can be structs/unions, including anonymous and nested structs. >> Cannot say that for sure but I think `ASTStructuralEquivalence` is easier to >> extend and to adopt for different purposes, while ODR hash seems to be more >> invasive. But this argument is more hand-wavy. >> >> Most likely `ASTStructuralEquivalence` has other positive qualities but >> that's what I was able to come up off the top of my head. And you can see >> that in my decision-making `ASTStructuralEquivalence` doesn't look like a >> compelling option. > > Makes sense. If most `Decl` classes had the member variables that enable ODR > hashing, would it make sense to keep structural equivalence logic around? > That sounds a bit redundant to me. Presumably `ASTStructuralEquivalence` can also be used as a tie-breaker in the case of a hash collision? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D124287/new/ https://reviews.llvm.org/D124287 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
