[flang-commits] [flang] [flang] Use fir.declare/fir.dummy_scope for TBAA tags attachments. (PR #92472)

[Slava Zakharin via flang-commits]

================
@@ -52,6 +52,38 @@ TBAABuilder::TBAABuilder(MLIRContext *context, bool applyTBAA,
                          bool forceUnifiedTree)
     : enableTBAA(applyTBAA && !disableTBAA),
       trees(/*separatePerFunction=*/perFunctionTBAATrees && !forceUnifiedTree) {
+  // TODO: the TBAA tags created here are rooted in the root scope
+  // of the enclosing function. This does not work best with MLIR inlining.
+  // A better approach is to root them according to the scopes they belong to
+  // and that were used by AddAliasTagsPass to create TBAA tags before
+  // the CodeGen. For example:
+  //   subroutine caller(a, b, ptr)
+  //     real, target :: a(:), b(:)
+  //     integer, pointer :: ptr(:)
+  //     call callee(a, b, ptr)
+  //   end
+  //   subroutine callee(a, b, ptr)
+  //     real :: a(:), b(:)
+  //     integer, pointer :: ptr(:)
+  //     do i=...
+  //       a(ptr(i)) = b(ptr(i))
+  //     end do
+  //   end
+  //
+  // When callee is inlined, the dummy arguments 'a' and 'b' will
+  // be rooted in TBAA tree corresponding to the `call callee` call site,
+  // saying that the references to 'a' and 'b' cannot alias each other.
+  // These tags will be created by AddAliasTagsPass, but it will not be able
+  // to create any tags for 'ptr' references.
+  // During the CodeGen, we create 'any data access' tags for the
+  // 'ptr' acceses. If they are rooted within the root scope of `caller`,
+  // they end up in a different TBAA tree with the 'a' and 'b' access
+  // tags, so 'ptr', 'a' and 'b' references MayAlias. Moreover,
+  // the box access of 'ptr' will also be in a different TBAA tree
+  // with 'a' and 'b' tags, meaning they can also alias.
+  // This will prevent LLVM vectorization even with memory conflict checks.
+  // It seems that we'd better move all TBAA tags assignment to
+  // AddAliasTagsPass, which can at least rely on the dummy arguments scopes.
----------------
vzakhari wrote:

Yes, the box loads/stores for SSA boxes are implicit.  Since the loads/stores only make problems after lowering to LLVM dialect, we can try to attack it from multiple directions:
* A local box load/store may be well disambiguated by LLVM alias analysis (without any TBAA) if we make sure that LLVM sees that its address is not escaping.  For example, this means that when an SSA box is passed to a function call, the resulting LLVM pointer argument has `nocapture` attribute.
* The SSA boxes that are function arguments, are converted to pointer function arguments, but these pointer arguments, by construction, are know not to alias anything within the function scope, so the corresponding function arguments may all have `noalias` attribute.

Just these two approaches may resolve a lot of LLVM aliasing issues for the SSA boxes.  If this is not enough we can also think about attaching TBAA tags to operations that produce unique SSA boxes (e.g. embox/rebox) and read from SSA boxes (e.g. box_addr), and then propagate these tags to the corresponding loads/stores in the CodeGen.  I am not in favor of this, because we will have to add TBAA attribute to many more FIR operations.

I think `nocapture` and `noalias` should work for many cases of SSA boxes, and for the explicit loads/stores of the boxes we can attach TBAA `descriptor member` tags in `AddAliasTagsPass` (with proper scoping) and propagate them in the CodeGen.

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