[flang] Introduce `AbstractResultOnGlobalOpt` pass

[unterumarmung]

Summary

This pass allows to convert operations
which use functions with abstract results to ones that do not.

Depends on D130087

[unterumarmung]

Rebased & updated tests

[unterumarmung]

I wonder if there's a chance that there'll be a function type with abstract results inside fir.global type. Is it possible? If so, how should it be handled?

[jeanPerier]

In D130088#3672158, @unterumarmung wrote:

I wonder if there's a chance that there'll be a function type with abstract results inside fir.global type. Is it possible? If so, how should it be handled?

That is a good point, I think it will probably happen once procedure pointers are lowered, and if the related function types are represented (currently, for dummy procedures, we always cast the function type before calls to the interface know at the call site).

In my opinion, it is fine if you leave a TODO for this case until we know more how we want to deal with procedure pointers (one difficulty I foresee if we fully type them, if how we will deal with derived type rewrites for function pointer components. I am not sure how one can replace a named type in MLIR.).

[unterumarmung]

In D130088#3676382, @jeanPerier wrote:

In D130088#3672158, @unterumarmung wrote:

I wonder if there's a chance that there'll be a function type with abstract results inside fir.global type. Is it possible? If so, how should it be handled?

That is a good point, I think it will probably happen once procedure pointers are lowered, and if the related function types are represented (currently, for dummy procedures, we always cast the function type before calls to the interface know at the call site).

In my opinion, it is fine if you leave a TODO for this case until we know more how we want to deal with procedure pointers (one difficulty I foresee if we fully type them, if how we will deal with derived type rewrites for function pointer components. I am not sure how one can replace a named type in MLIR.).

Ok! What is the best way to do this?

1. For a simple procedure pointer this expression probably is not enough. because I think procedure pointers will have FunctionType nested like !fir.ptr<() ->()> or !fir.boxproc<() -> ()>, so I need to iterate depth-wise

global.getType().cast<FunctionType>()

2. For the procedure components the situation is more interesting. For the program in this comment, if I comment all of the TODO(..., "support for polymorphic types"), I get this code. It's just lowering, without optimization and transformation. I can't quite understand what is happening there and how I should handle it.

Any help is appreciated, thanks!

[jeanPerier]

In D130088#3678929, @unterumarmung wrote:

In D130088#3676382, @jeanPerier wrote:

In D130088#3672158, @unterumarmung wrote:

I wonder if there's a chance that there'll be a function type with abstract results inside fir.global type. Is it possible? If so, how should it be handled?

That is a good point, I think it will probably happen once procedure pointers are lowered, and if the related function types are represented (currently, for dummy procedures, we always cast the function type before calls to the interface know at the call site).

In my opinion, it is fine if you leave a TODO for this case until we know more how we want to deal with procedure pointers (one difficulty I foresee if we fully type them, if how we will deal with derived type rewrites for function pointer components. I am not sure how one can replace a named type in MLIR.).

Ok! What is the best way to do this?

1. For a simple procedure pointer this expression probably is not enough. because I think procedure pointers will have FunctionType nested like !fir.ptr<() ->()> or !fir.boxproc<() -> ()>, so I need to iterate depth-wise

Yes, although I do not know yet if we will lower the function type to something else than () -> () in the procedure pointer types or if we will keep relying on function type cast on the call site. Rewriting types, especially in nested structures involving named types does not look like a fun journey, so we may want to keep the types as () -> (), we should weight the pros and cons when dealing with procedure pointers.

Right now you could probably check if the global type needs to be rewritten (if it contains a nested function type), in which case you could emit a TODO(loc, ....).

2. For the procedure components the situation is more interesting. For the program in this comment, if I comment all of the TODO(..., "support for polymorphic types"), I get this code. It's just lowering, without optimization and transformation. I can't quite understand what is happening there and how I should handle it.

I do not think there is anything required here on top of what you have done. The issue with procedure components was that:

• For derived types, semantics is creating compiler generated read-only globals that describe the derived type to the runtime (the _QMaE.dt.f fir.global in your example). See https://github.com/llvm/llvm-project/blob/main/flang/docs/RuntimeTypeInfo.md for more info about this.

• These data structures are describing the procedure components so that the runtime can resolve calls involving CLASS(T). They are using the ISO C c_funptr type to hold the pointers, and this type erase the function types in the data structure. However, the FIR operations inserting the actual procedure component address into the fir.global are dealing with the actual function type:

%3 = fir.address_of(@_QMaPfoo) : (!fir.box<!fir.type<_QMaTf>>) -> !fir.box<!fir.heap<!fir.char<1,?>>>
 %c-1 = arith.constant -1 : index
 %4 = fir.field_index __address, !fir.type<_QM__fortran_builtinsT__builtin_c_funptr{__address:i64}>
 %5 = fir.convert %3 : ((!fir.box<!fir.type<_QMaTf>>) -> !fir.box<!fir.heap<!fir.char<1,?>>>) -> i64
 %6 = fir.undefined !fir.type<_QM__fortran_builtinsT__builtin_c_funptr{__address:i64}>
 %7 = fir.insert_value %6, %5, ["__address", !fir.type<_QM__fortran_builtinsT__builtin_c_funptr{__address:i64}>] : (!fir.type<_QM__fortran_builtinsT__builtin_c_funptr{__address:i64}>, i64) -> !fir.type<_QM__fortran_builtinsT__builtin_c_funptr{__address:i64}>
  ....

Hence, the fir.address_of inside the GlobalOp needed to be rewritten if it dealt with functions returning arrays or descriptors, which is what your patch should enable.

Note that procedure components are not represented in FIR fir.type derived types because they are not data objects. So There is no rewrite needed in the related fir.type.

[unterumarmung]

Rebased

[jeanPerier]

flang/include/flang/Optimizer/Transforms/Passes.h

13

Small style question, it looks like clang-format is happy with your change, but is it from MLIR/LLVM style to add blank lines between the headers from different parts ? I am not sure we are doing it in other files.

flang/test/Fir/abstract-results.fir

320

The cases with alloca/calls inside global op are a bit unrealistic: at least at the LLVM dialect level that is forbidden, the region should be constant foldable to a compile time constant. Now, given we do not enforce this in the fir.global verifier, I am not completely against having these tests (in a far fetch future we could imagine doing some mandatory inlining of "constexpr" functions + mem to reg in the fir global op bodies, but that is very unlikely).

[schweitz]

What is the motivating Fortran example here?

flang/include/flang/Optimizer/Transforms/Passes.h

13

Don't use blank lines.

flang/lib/Optimizer/Transforms/AbstractResult.cpp

313

The name of this pass appears to have nothing to do with the description.

What is really going on?

flang/test/Fir/abstract-results.fir

320

Agreed.

I suspect this isn't a necessary extension to FIR. Is there an actual example of Fortran code that requires this?

[unterumarmung]

In D130088#3682390, @schweitz wrote:

What is the motivating Fortran example here?

The motivating example code is here: https://reviews.llvm.org/D130369#3672155
I get a TODO error I removed in the patch if I remove all of TODO(..., "support for polymorphic types") first.

I decided to implement this because there have been code written for FuncOp, so all I needed to do is to refactor some things and handling of the GlobalOp.

flang/include/flang/Optimizer/Transforms/Passes.h

13

Ok

flang/lib/Optimizer/Transforms/AbstractResult.cpp

313

This pass converts operations that

1. Use a function type with an abstract result
2. Are inside of a fir::GlobalOp

to an equivalent instruction without the abstract result.

313

How should I rename the pass?

flang/test/Fir/abstract-results.fir

320

There is no motivating example for this test particularly.
I just adapted as much of the FuncOp tests as possible like a proof of concept.

So, I should remove all of GlobalOp tests which contain fir.alloca and any call instructions?

[unterumarmung]

@jeanPerier, thank you for the detailed reply, It has been really helpful!

In D130088#3679322, @jeanPerier wrote:

Yes, although I do not know yet if we will lower the function type to something else than () -> () in the procedure pointer types or if we will keep relying on function type cast on the call site. Rewriting types, especially in nested structures involving named types does not look like a fun journey, so we may want to keep the types as () -> (), we should weight the pros and cons when dealing with procedure pointers.

Ok! But I got stuck on this.
What I think the best solution is traversing all of the nested types of the given type of GlobalOp until we find a function type with an abstract type or don't find it at all.
But fir::GlobalOp::getType() returns a mlir::Type object. It doesn't have any methods to return a list of type parameters. Is there a way to get it? Could you please give some tips?

In D130088#3679322, @jeanPerier wrote:

Note that procedure components are not represented in FIR fir.type derived types because they are not data objects. So There is no rewrite needed in the related fir.type.

Interesting, so what I've been trying to do here is completely wrong..

[unterumarmung]

Rebased & added TODO

[unterumarmung]

@jeanPerier, since there is no generic way to iterate through type parameters, I added a type switch for the TODO

[rriddle]

In D130088#3682836, @unterumarmung wrote:

@jeanPerier, thank you for the detailed reply, It has been really helpful!

In D130088#3679322, @jeanPerier wrote:

Yes, although I do not know yet if we will lower the function type to something else than () -> () in the procedure pointer types or if we will keep relying on function type cast on the call site. Rewriting types, especially in nested structures involving named types does not look like a fun journey, so we may want to keep the types as () -> (), we should weight the pros and cons when dealing with procedure pointers.

Ok! But I got stuck on this.
What I think the best solution is traversing all of the nested types of the given type of GlobalOp until we find a function type with an abstract type or don't find it at all.
But fir::GlobalOp::getType() returns a mlir::Type object. It doesn't have any methods to return a list of type parameters. Is there a way to get it? Could you please give some tips?

The closest thing that will give you what you want is the SubElement interfaces: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/IR/SubElementInterfaces.td

They provide API for walking sub attributes/types.

[schweitz]

flang/lib/Optimizer/Transforms/AbstractResult.cpp

313

Maybe something that conveys "transformation of calls that return abstract results in a global". The name suggested to me that it was rewriting globals to have abstract types. Which seems quite odd.

flang/lib/Optimizer/Transforms/PassDetail.h

13

nit: blank line

flang/test/Fir/abstract-results.fir

269

I think the compiler should simply ban the use of alloca and allocmem in GlobalOp.

A GlobalOp is expected to have no resources and not be able to acquire any resources. So memory allocation, function calls, etc. just do not make much sense in a GlobalOp. More precisely, a GlobalOp is expected to become bits in a .data, .rodata, or .bss section of the object file. It's "code" is meant to construct an initial value at compile-time only—it's body should never, in practice, become executable code.

Given that, it doesn't seem like this pass is needed.

[unterumarmung]

flang/test/Fir/abstract-results.fir

269

I see your point.
But this is the easiest way to "solve" this TODO: https://reviews.llvm.org/D130369, that's why I implemented it like this.
What is the best/expected way to do this?

[unterumarmung]

In D130088#3695972, @rriddle wrote:

In D130088#3682836, @unterumarmung wrote:

@jeanPerier, thank you for the detailed reply, It has been really helpful!

In D130088#3679322, @jeanPerier wrote:

Yes, although I do not know yet if we will lower the function type to something else than () -> () in the procedure pointer types or if we will keep relying on function type cast on the call site. Rewriting types, especially in nested structures involving named types does not look like a fun journey, so we may want to keep the types as () -> (), we should weight the pros and cons when dealing with procedure pointers.

Ok! But I got stuck on this.
What I think the best solution is traversing all of the nested types of the given type of GlobalOp until we find a function type with an abstract type or don't find it at all.
But fir::GlobalOp::getType() returns a mlir::Type object. It doesn't have any methods to return a list of type parameters. Is there a way to get it? Could you please give some tips?

The closest thing that will give you what you want is the SubElement interfaces: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/IR/SubElementInterfaces.td

They provide API for walking sub attributes/types.

Yes, but to use this, I need to change the definitions of the types I want to iterate through, which is overkill in this particular situation.
Thank you for the information, I'll keep this in mind!

[jeanPerier]

In D130088#3695972, @rriddle wrote:

The closest thing that will give you what you want is the SubElement interfaces: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/IR/SubElementInterfaces.td

Thanks for pointing that out @rriddle, we will definitely want to use this in flang to ease all the passes that need to visit types, and to get nice type aliasing when printing nested types.

In D130088#3697172, @unterumarmung wrote:

Yes, but to use this, I need to change the definitions of the types I want to iterate through, which is overkill in this particular situation.
Thank you for the information, I'll keep this in mind!

I agree that adding the generic visit is outside of the scope of your patch. Your "containsFunctionTypeWithAbstractResult" function does the job of making to insert the TODO, we will take it when it is clear of Procedure pointer types should be represented.

flang/test/Fir/abstract-results.fir

269

@schweitz, the pass is needed to rewrite the fir::AddrOfOp to function inside GlobalOp, which are legal and makes sense. Because the pass re-uses the FuncOp pass logic, it comes with patterns for CallOp and such: we simply do not care about those in the context of a GlobalOp, we should not have these operation in a GlobalOp.

The GloablOp pass could also just share the fir::AddrOfOp registration and pattern logic to avoid being misleading. The downside being that if some new Operation that may refer to a function symbol is used and can be used in both GlobalOp and FuncOp, one would have to not forget adding it to both passes. With the current approach, they would be registered for all passes, and just unused if it is not possible to have the related op in a GloablOp anyway.

320

So, I should remove all of GlobalOp tests which contain fir.alloca and any call instructions?

Yes, I think it may mislead people using tests as an example of what FIR canonical patterns are.

[schweitz]

flang/test/Fir/abstract-results.fir

269

Thanks, Jean.

100% agree that all function types should be rewritten to correspond appropriately to the low-level target and that includes any (legal) addr_of Ops in a GlobalOp.

[unterumarmung]

1. Rebase
2. Remove blank lines
3. Remove non-conforming tests

[unterumarmung]

Hey, @jeanPerier @schweitz! Sorry for the delay

I rebased my patch and addressed most of the review comment. Could you please take a look?

flang/lib/Optimizer/Transforms/AbstractResult.cpp

313

Maybe, AbstractResultInGlobalOpt? :)

[jeanPerier]

Thanks for addressing the comments, LGTM

[unterumarmung]

Rebased

flang/include/flang/Optimizer/Transforms/Passes.h

 //===-- Optimizer/Transforms/Passes.h ---------------------------*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef FORTRAN_OPTIMIZER_TRANSFORMS_PASSES_H
 #define FORTRAN_OPTIMIZER_TRANSFORMS_PASSES_H
 
+#include "flang/Optimizer/Dialect/FIROps.h"
 #include "mlir/Pass/Pass.h"
 #include "mlir/Pass/PassRegistry.h"
 #include <memory>
 
 namespace mlir {
 class BlockAndValueMapping;
 class Operation;
 class Pass;
 class Region;
 } // namespace mlir
 
 namespace fir {
 
 //===----------------------------------------------------------------------===//
 // Passes defined in Passes.td
 //===----------------------------------------------------------------------===//
 
 std::unique_ptr<mlir::Pass> createAbstractResultOnFuncOptPass();
+std::unique_ptr<mlir::Pass> createAbstractResultOnGlobalOptPass();
 std::unique_ptr<mlir::Pass> createAffineDemotionPass();
 std::unique_ptr<mlir::Pass> createArrayValueCopyPass();
 std::unique_ptr<mlir::Pass> createFirToCfgPass();
 std::unique_ptr<mlir::Pass> createCharacterConversionPass();
 std::unique_ptr<mlir::Pass> createExternalNameConversionPass();
 std::unique_ptr<mlir::Pass> createMemDataFlowOptPass();
 std::unique_ptr<mlir::Pass> createPromoteToAffinePass();
 std::unique_ptr<mlir::Pass> createMemoryAllocationPass();

flang/include/flang/Optimizer/Transforms/Passes.td

Option<"passResultAsBox", "abstract-result-as-box",
            " of fir.ref<fir.array<T>>.">
   ];
 }
 
 def AbstractResultOnFuncOpt : AbstractResultOptBase<"func", "mlir::func::FuncOp"> {
   let constructor = "::fir::createAbstractResultOnFuncOptPass()";
 }
 
+def AbstractResultOnGlobalOpt : AbstractResultOptBase<"global", "fir::GlobalOp"> {
+  let constructor = "::fir::createAbstractResultOnGlobalOptPass()";
+}
+
 def AffineDialectPromotion : Pass<"promote-to-affine", "::mlir::func::FuncOp"> {
   let summary = "Promotes `fir.{do_loop,if}` to `affine.{for,if}`.";
   let description = [{
     Convert fir operations which satisfy affine constraints to the affine
     dialect.
 
     `fir.do_loop` will be converted to `affine.for` if the loops inside the body
     can be converted and the indices for memory loads and stores satisfy

flang/include/flang/Tools/CLOptions.inc

inline void createDefaultFIROptimizerPassPipeline(
   pm.addPass(mlir::createCSEPass());
 }
 
 #if !defined(FLANG_EXCLUDE_CODEGEN)
 inline void createDefaultFIRCodeGenPassPipeline(mlir::PassManager &pm) {
   fir::addBoxedProcedurePass(pm);
   pm.addNestedPass<mlir::func::FuncOp>(
       fir::createAbstractResultOnFuncOptPass());
+  pm.addNestedPass<fir::GlobalOp>(
+      fir::createAbstractResultOnGlobalOptPass());
   fir::addCodeGenRewritePass(pm);
   fir::addTargetRewritePass(pm);
   fir::addExternalNameConversionPass(pm);
   fir::addFIRToLLVMPass(pm);
 }
 
 /// Create a pass pipeline for lowering from MLIR to LLVM IR
 ///

flang/lib/Optimizer/Transforms/AbstractResult.cpp

if (hasAbstractResult(funcTy)) {
         }
         patterns.insert<ReturnOpConversion>(context, newArg);
         target.addDynamicallyLegalOp<mlir::func::ReturnOp>(
             [](mlir::func::ReturnOp ret) { return ret.operands().empty(); });
       }
     }
   }
 };
+
+inline static bool containsFunctionTypeWithAbstractResult(mlir::Type type) {
+  return mlir::TypeSwitch<mlir::Type, bool>(type)
+      .Case([](fir::BoxProcType boxProc) {
+        return fir::hasAbstractResult(
+            boxProc.getEleTy().cast<mlir::FunctionType>());
+      })
+      .Case([](fir::PointerType pointer) {
+        return fir::hasAbstractResult(
+            pointer.getEleTy().cast<mlir::FunctionType>());
+      })
+      .Default([](auto &&) { return false; });
+}
+
+class AbstractResultOnGlobalOpt
+    : public AbstractResultOptTemplate<AbstractResultOnGlobalOpt,
+                                       fir::AbstractResultOnGlobalOptBase> {
+public:
+  void runOnSpecificOperation(fir::GlobalOp global, bool,
+                              mlir::RewritePatternSet &,
+                              mlir::ConversionTarget &) {
+    if (containsFunctionTypeWithAbstractResult(global.getType())) {
+      TODO(global->getLoc(), "support for procedure pointers");
+    }
+  }
+};
 } // end anonymous namespace
 } // namespace fir
 
 std::unique_ptr<mlir::Pass> fir::createAbstractResultOnFuncOptPass() {
   return std::make_unique<AbstractResultOnFuncOpt>();
 }
+
+std::unique_ptr<mlir::Pass> fir::createAbstractResultOnGlobalOptPass() {
+  return std::make_unique<AbstractResultOnGlobalOpt>();
+}

flang/lib/Optimizer/Transforms/PassDetail.h

 //===- PassDetail.h - Optimizer Transforms Pass class details ---*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 #ifndef FORTRAN_OPTMIZER_TRANSFORMS_PASSDETAIL_H
 #define FORTRAN_OPTMIZER_TRANSFORMS_PASSDETAIL_H
 
 #include "flang/Optimizer/Dialect/FIRDialect.h"
+#include "flang/Optimizer/Dialect/FIROps.h"
 #include "mlir/Dialect/Affine/IR/AffineOps.h"
 #include "mlir/Dialect/Func/IR/FuncOps.h"
 #include "mlir/Dialect/LLVMIR/LLVMDialect.h"
 #include "mlir/Dialect/Math/IR/Math.h"
 #include "mlir/Dialect/OpenACC/OpenACC.h"
 #include "mlir/Dialect/OpenMP/OpenMPDialect.h"
 #include "mlir/Pass/Pass.h"
 #include "mlir/Pass/PassRegistry.h"
 
 namespace fir {
 
 #define GEN_PASS_CLASSES
 #include "flang/Optimizer/Transforms/Passes.h.inc"
 
 } // namespace fir
 
 #endif // FORTRAN_OPTMIZER_TRANSFORMS_PASSDETAIL_H

flang/test/Driver/mlir-pass-pipeline.f90

 ! ALL-NEXT: SCFToControlFlow
 ! ALL-NEXT: Canonicalizer
 ! ALL-NEXT: SimplifyRegionLite
 ! ALL-NEXT: CSE
 ! ALL-NEXT:   (S) 0 num-cse'd - Number of operations CSE'd
 ! ALL-NEXT:   (S) 0 num-dce'd - Number of operations DCE'd
 ! ALL-NEXT: BoxedProcedurePass
 
-! ALL-NEXT: 'func.func' Pipeline
-! ALL-NEXT:   AbstractResultOnFuncOpt
+! ALL-NEXT: Pipeline Collection : ['fir.global', 'func.func']
+! ALL-NEXT:   'fir.global' Pipeline
+! ALL-NEXT:    AbstractResultOnGlobalOpt
+! ALL-NEXT:  'func.func' Pipeline
+! ALL-NEXT:    AbstractResultOnFuncOpt
 
 ! ALL-NEXT: CodeGenRewrite
 ! ALL-NEXT:   (S) 0 num-dce'd - Number of operations eliminated
 ! ALL-NEXT: TargetRewrite
 ! ALL-NEXT: ExternalNameConversion
 ! ALL-NEXT: FIRToLLVMLowering
 ! ALL-NOT: LLVMIRLoweringPass

flang/test/Fir/abstract-results.fir

 // Test rewrite of functions that return fir.array<>, fir.type<>, fir.box<> to
 // functions that take an additional argument for the result.
 
 // RUN: fir-opt %s --abstract-result-on-func-opt | FileCheck %s --check-prefix=FUNC-REF
 // RUN: fir-opt %s --abstract-result-on-func-opt=abstract-result-as-box | FileCheck %s --check-prefix=FUNC-BOX
+// RUN: fir-opt %s --abstract-result-on-global-opt | FileCheck %s --check-prefix=GLOBAL-REF
+// RUN: fir-opt %s --abstract-result-on-global-opt=abstract-result-as-box | FileCheck %s --check-prefix=GLOBAL-BOX
 
 // ----------------------- Test declaration rewrite ----------------------------
 
 // FUNC-REF-LABEL:  func private @arrayfunc(!fir.ref<!fir.array<?xf32>>, i32)
 // FUNC-BOX-LABEL:  func private @arrayfunc(!fir.box<!fir.array<?xf32>>, i32)
 func.func private @arrayfunc(i32) -> !fir.array<?xf32>
 
 // FUNC-REF-LABEL:  func private @derivedfunc(!fir.ref<!fir.type<t{x:f32}>>, f32)
func.func @test_indirect_calls(%arg0: () -> ()) {
   // FUNC-BOX: %[[buffer:.*]] = fir.alloca !fir.array<?xf32>, %[[c100]]
   // FUNC-BOX: %[[shape:.*]] = fir.shape %[[c100]] : (index) -> !fir.shape<1>
   // FUNC-BOX: %[[original_conv:.*]] = fir.convert %[[arg0]] : (() -> ()) -> ((index) -> !fir.array<?xf32>)
   // FUNC-BOX: %[[box:.*]] = fir.embox %[[buffer]](%[[shape]]) : (!fir.ref<!fir.array<?xf32>>, !fir.shape<1>) -> !fir.box<!fir.array<?xf32>>
   // FUNC-BOX: %[[conv:.*]] = fir.convert %[[original_conv]] : ((index) -> !fir.array<?xf32>) -> ((!fir.box<!fir.array<?xf32>>, index) -> ())
   // FUNC-BOX: fir.call %[[conv]](%[[box]], %c100) : (!fir.box<!fir.array<?xf32>>, index) -> ()
   // FUNC-BOX-NOT: fir.save_result
 }
+
+// ----------------------- Test GlobalOp rewrite ------------------------
+
+// This is needed to separate GlobalOp tests from FuncOp tests for FileCheck
+// FUNC-REF-LABEL: fir.global {{.*}} : {{.*}} {
+// FUNC-BOX-LABEL: fir.global {{.*}} : {{.*}} {
+
+// GLOBAL-REF-LABEL: fir.global @global_test_address_of : i32 {
+// GLOBAL-BOX-LABEL: fir.global @global_test_address_of : i32 {
+fir.global @global_test_address_of : i32 {
+  %0 = fir.address_of(@arrayfunc) : (i32) -> !fir.array<?xf32>
+
+  // GLOBAL-REF: %[[addrOf:.*]] = fir.address_of(@arrayfunc) : (!fir.ref<!fir.array<?xf32>>, i32) -> ()
+  // GLOBAL-REF: %[[conv:.*]] = fir.convert %[[addrOf]] : ((!fir.ref<!fir.array<?xf32>>, i32) -> ()) -> ((i32) -> !fir.array<?xf32>)
+
+  // GLOBAL-BOX: %[[addrOf:.*]] = fir.address_of(@arrayfunc) : (!fir.box<!fir.array<?xf32>>, i32) -> ()
+  // GLOBAL-BOX: %[[conv:.*]] = fir.convert %[[addrOf]] : ((!fir.box<!fir.array<?xf32>>, i32) -> ()) -> ((i32) -> !fir.array<?xf32>)
+
+  %c42 = arith.constant 42 : i32
+  fir.has_value %c42 : i32
+}

flang/test/Fir/basic-program.fir

 // PASSES-NEXT: SCFToControlFlow
 // PASSES-NEXT: Canonicalizer
 // PASSES-NEXT: SimplifyRegionLite
 // PASSES-NEXT: CSE
 // PASSES-NEXT:   (S) 0 num-cse'd - Number of operations CSE'd
 // PASSES-NEXT:   (S) 0 num-dce'd - Number of operations DCE'd
 // PASSES-NEXT: BoxedProcedurePass
 
-// PASSES-NEXT: 'func.func' Pipeline
-// PASSES-NEXT:   AbstractResultOnFuncOpt
+// PASSES-NEXT: Pipeline Collection : ['fir.global', 'func.func']
+// PASSES-NEXT:   'fir.global' Pipeline
+// PASSES-NEXT:    AbstractResultOnGlobalOpt
+// PASSES-NEXT:  'func.func' Pipeline
+// PASSES-NEXT:    AbstractResultOnFuncOpt
 
 // PASSES-NEXT: CodeGenRewrite
 // PASSES-NEXT:   (S) 0 num-dce'd - Number of operations eliminated
 // PASSES-NEXT: TargetRewrite
 // PASSES-NEXT: FIRToLLVMLowering
 // PASSES-NEXT: LLVMIRLoweringPass