[flang-commits] [libcxx] [libc] [clang] [clang-tools-extra] [compiler-rt] [flang] [llvm] [Clang] Generate the GEP instead of adding AST nodes (PR #73730)

[Bill Wendling via flang-commits]

================
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const ArraySubscriptExpr *E,
       ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
     else
       ArrayLV = EmitLValue(Array);
+
     auto *Idx = EmitIdxAfterBase(/*Promote*/true);
 
+    if (SanOpts.has(SanitizerKind::ArrayBounds)) {
----------------
bwendling wrote:

> You should be able to refactor some code out of CodeGenFunction::EmitMemberExpr so it's not a completely independent codepath.

I could use it as a template, but refactoring probably won't work very well, because even if I could call it to generate the FAM array access, I don't have an Expr for the count.

> the nastiest problems are caused by one piece of code making assumptions about how an apparently unrelated part of the code behaves.

This is why I'm being very stubborn about *not* skipping the existing Emit functions. The assumption we're making are that generating the GEPs by hand for both fields is "easy". We can make that assumption for the `count` field, because of the expectations I mentioned above (how it's at the top-level of the struct, etc.). But I don't want to make those assumptions about the flexible array field.

As it turns out, I should be able to use `getSourceElementType` on a GEP to know when to stop skipping GEPs.

Keep in mind, the code we generate is for bounds checking, so we have a fallback if we're unable to generate a proper bounds check using the `count`. I.e., if we run into something unexpected, we can abort the bounds checking generation.

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