[clang] [Clang][objectsize] Generate object size calculation for sub-objects (PR #86858)

[Bill Wendling via cfe-commits]

================
@@ -1062,6 +1063,159 @@ CodeGenFunction::emitFlexibleArrayMemberSize(const Expr *E, unsigned Type,
   return Builder.CreateSelect(Cmp, Res, ConstantInt::get(ResType, 0, IsSigned));
 }
 
+namespace {
+
+class ObjectSizeVisitor
+    : public ConstStmtVisitor<ObjectSizeVisitor, const Expr *> {
+  bool SkipASE;
+
+public:
+  ObjectSizeVisitor(bool SkipASE = false) : SkipASE(SkipASE) {}
+
+  const Expr *Visit(const Expr *E) {
+    return ConstStmtVisitor<ObjectSizeVisitor, const Expr *>::Visit(E);
+  }
+
+  const Expr *VisitStmt(const Stmt *S) { return nullptr; }
+
+  const Expr *VisitDeclRefExpr(const DeclRefExpr *E) { return E; }
+  const Expr *VisitMemberExpr(const MemberExpr *E) { return E; }
+  const Expr *VisitArraySubscriptExpr(const ArraySubscriptExpr *E) {
+    return SkipASE ? Visit(E->getBase()) : E;
+  }
+
+  const Expr *VisitCastExpr(const CastExpr *E) {
+    return Visit(E->getSubExpr());
+  }
+  const Expr *VisitParenExpr(const ParenExpr *E) {
+    return Visit(E->getSubExpr());
+  }
+  const Expr *VisitUnaryAddrOf(const clang::UnaryOperator *E) {
+    return Visit(E->getSubExpr());
----------------
bwendling wrote:

My knowledge of the front-end's architecture isn't perfect, but it seems like supporting that type of aliasing in the front-end isn't easy. For your example, the code reverts to using the `llvm.objectsize` intrinsic on the result of `EmitScalarExpr(p)`. This can be seen as a deficiency, but according to others it's "acceptable" to return such in this case. I intend to expand the use of this function with future changes, where it may be possible to support this type of aliasing. But we'll always have issues with things like:

```c
unsigned __attribute__((always_inline)) foo(void *p) {
  return __builtin_dynamic_object_size(p, 1);
}

void bar(int y) {
  int *x[10];

  foo((void *)x[y]);
}
```

because we don't perform inlining in the front-end. For that, we'll need to "fix" the `llvm.objectsize` intrinsic, but it's tougher than it looks.

https://github.com/llvm/llvm-project/pull/86858