[flang-commits] [flang] [flang] AliasAnalysis: Handle fir.load on fir.alloca (PR #117785)
Joel E. Denny via flang-commits
flang-commits at lists.llvm.org
Wed Nov 27 08:34:37 PST 2024
================
@@ -522,6 +546,12 @@ AliasAnalysis::Source AliasAnalysis::getSource(mlir::Value v,
.Case<fir::AllocaOp, fir::AllocMemOp>([&](auto op) {
// Unique memory allocation.
type = SourceKind::Allocate;
+ // If there's no DeclareOp, then we need to get the pointer attribute
+ // from the type. TODO: That case occurs in our test suite
+ // (alias-analysis-2.fir), but does flang currently generate such
+ // code?
+ if (isPointerReference(ty))
+ attributes.set(Attribute::Pointer);
----------------
jdenny-ornl wrote:
Thanks, check-flang passes with that change. But can you help me to understand the following points?
1. In alias-analysis-2.fir, `p1.addr` is `fir.alloca !fir.ptr<f32>`. I understood that to be pointer non-data (i.e., address of a pointer not of its target). After applying your suggestion, getSource labels it as non-pointer data instead. How is the latter correct?
2. As this PR's todo comment asks, when does flang generate something like `fir.alloca !fir.ptr<f32>`? What semantics does it represent in Fortran?
3. This PR's approach of adding `attributes.set(Attribute::Pointer)` to getSource's AllocaOp case seems consistent with the existing AddrOfOp and dummy arg cases (the two cases that getSource already handles after LoadOp). Your suggestion makes AllocaOp inconsistent with AddrOfOp and dummy args. Why is that inconsistency correct?
https://github.com/llvm/llvm-project/pull/117785
More information about the flang-commits
mailing list