efriedma-quic wrote: Trying to summarize my understanding here:
- Using the type of an alloca in LLVM IR is wrong, for a variety of reasons. (At this point, the type of an alloca is basically just leftover junk from before the opaque pointer transition; I expect that we'll kill it off completely at some point.) - There's some dispute over what it means to compute the size of a subobject "conservatively", in particular what's supposed to happen if we can't identify a subobject. - clang returns significantly worse results than gcc in many cases because we don't encode subobject information into LLVM IR, and there's no IR between clang ASTs and LLVM IR we can use for this sort of analysis. Encoding the information into LLVM IR (metadata on allocas, or something like that) might be feasible, but tricky to design well. Doing dataflow analysis directly on the clang AST is extremely complicated and bug-prone because we don't directly encode control flow. - Both gcc and LLVM compute object sizes after optimization in some cases; it's impossible to completely replicate that behavior because it depends on unrelated optimizations driven by heuristics. But that's not really relevant for the cases we're discussing here. https://github.com/llvm/llvm-project/pull/78526 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
