efriedma-quic wrote: > > Making Sema pull the TBAA info out of clang/lib/CodeGen is a layering > > violation (and probably breaks if we aren't actually generating code). If > > we need some notion of "aliasing" in Sema, we should pull the relevant code > > into clang/lib/AST. > > That's unfortunate. The code will not call the TBAA stuff if the code > generator doesn't provide that predicate -- so if not generating optimized > code the warning is inactive. This is the same as with GCC btw. To be clear > what's exposed is a new predicate allowing querying of type conversion's > TBAAness -- the representations of TBAA etc are not exposed. The CodeGen TBAA > machinery builds on llvm's aliasing MDNodes. It would seem a large task to > replicate that in AST (and I presume propagating llvm's bits further into AST > is even worse?)
On the LLVM side, there's very little interesting logic; it's basically just walking the tree of metadata nodes generated by clang. See https://llvm.org/docs/LangRef.html#tbaa-node-semantics . The hard part of the refactoring would just be adding an abstraction for the underlying information. gcc has made various unfortunate decisions regarding diagnostics in the past; we've put a lot of effort into making sure our diagnostics are more consistent. https://github.com/llvm/llvm-project/pull/74155 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
