[flang] add memory effects interface to (hl)fir.declare

[tblah]

Summary

These operations should have no memory effect, but doing so causes the
declare to be removed by dead code elimination if the result value is
unused. fir.declare is intended to be used to generate debug information
about variables. Debug information may still be desirable even about
unused variables, so we don't want to remove the declare operations when
performing dead code elimination.

[vzakhari]

I would prefer it to be modeled as a write effect of a new "debugger" resource. And the write effect should be only reported under -g.

[tblah]

Thanks for review.

I've updated to use MemWrite to a debugging resource. It isn't easy to make
memory effects runtime conditional so I haven't made it conditional on -g,
which I think is good because otherwise people might not test and optimizations
won't run with -g.

I agree that writing to a debugging resource sounds more right linguisticly. But
I think it is unfortunate that now we have to remember to code in checks for
this debugging resource into optimization passes (if a pass looks for writes
which might alias with some value without looking at the resource, it will have
to assume this operation does because it is a write on an unspecified value).
Fortunately, we don't need upstream mlir passes (like CSE) to work on DeclareOp.

Semantically, an allocation is a better fit because you can't remove it but it
is known not to effect anything else.

[vzakhari]

Thank you, Tom! Let's try keeping it this way. If this causes performance issues, we will revisit it.

It would be great to have some LIT test for this, e.g. like mlir/test/IR/test-side-effects.mlir.

[tblah]

In D157626#4580693, @vzakhari wrote:

Thank you, Tom! Let's try keeping it this way. If this causes performance issues, we will revisit it.

It would be great to have some LIT test for this, e.g. like mlir/test/IR/test-side-effects.mlir.

It'll be covered in tests for https://reviews.llvm.org/D157107 when I update it.

But yes, ideally all FIR and HLFIR ops would have their side effects tested like that

[vzakhari]

In D157626#4580703, @tblah wrote:

It'll be covered in tests for https://reviews.llvm.org/D157107 when I update it.

Sounds good. Thank you!

flang/include/flang/Optimizer/Dialect/FIRAttr.td

def fir_FortranVariableFlagsAttr : fir_Attr<"FortranVariableFlags"> {
   );
   let hasCustomAssemblyFormat = 1;
   let returnType = "::fir::FortranVariableFlagsEnum";
   let convertFromStorage = "$_self.getFlags()";
   let constBuilderCall =
           "::fir::FortranVariableFlagsAttr::get($_builder.getContext(), $0)";
 }
 
+// mlir::SideEffects::Resource for modelling operations which add debugging information
+def DebuggingResource : Resource<"::fir::DebuggingResource">;
+
 #endif // FIR_DIALECT_FIR_ATTRS

flang/include/flang/Optimizer/Dialect/FIROps.h

 static constexpr llvm::StringRef getAdaptToByRefAttrName() {
   return "adapt.valuebyref";
 }
 
 static constexpr llvm::StringRef getNormalizedLowerBoundAttrName() {
   return "normalized.lb";
 }
 
+/// Model operations which affect global debugging information
+struct DebuggingResource
+    : public mlir::SideEffects::Resource::Base<DebuggingResource> {
+  mlir::StringRef getName() final { return "DebuggingResource"; }
+};
+
 } // namespace fir
 
 #define GET_OP_CLASSES
 #include "flang/Optimizer/Dialect/FIROps.h.inc"
 
 #endif // FORTRAN_OPTIMIZER_DIALECT_FIROPS_H

flang/include/flang/Optimizer/Dialect/FIROps.td

let description = [{
     ```
   }];
 
   let arguments = (ins AnyRefOrBoxLike:$val);
 
   let results = (outs BoolLike);
 }
 
+// fir.declare leads to no codegen so the side effects implementation should be
+// Pure. However, this would allow dead code elimination to remove these
+// operations if the values are unused. fir.declare may be used to generate
+// debug information so we would like to keep this around even if the value
+// is not used.
 def fir_DeclareOp : fir_Op<"declare", [AttrSizedOperandSegments,
+    MemoryEffects<[MemWrite<DebuggingResource>]>,
     DeclareOpInterfaceMethods<fir_FortranVariableOpInterface>]> {
   let summary = "declare a variable";
 
   let description = [{
     Tie the properties of a Fortran variable to an address. The properties
     include bounds, length parameters, and Fortran attributes.
 
     The memref argument describes the storage of the variable. It may be a

flang/include/flang/Optimizer/HLFIR/HLFIROps.td

 include "mlir/IR/BuiltinAttributes.td"
 
 // Base class for FIR operations.
 // All operations automatically get a prefix of "hlfir.".
 class hlfir_Op<string mnemonic, list<Trait> traits>
   : Op<hlfir_Dialect, mnemonic, traits>;
 
 
-
+// DeclareOp can be lowered to EmboxOp, EmboxCharOp, ReboxOp, etc and so could
+// generate code. All of the operations it can generate are modelled with
+// NoMemoryEffect. However, if hlfir.declare is given NoMemoryEffect, it can be
+// removed by dead code elimination if the value result is unused. Information
+// from the delclare operation can be used to generate debug information so we
+// don't want to remove it as dead code
 def hlfir_DeclareOp : hlfir_Op<"declare", [AttrSizedOperandSegments,
+    MemoryEffects<[MemWrite<DebuggingResource>]>,
     DeclareOpInterfaceMethods<fir_FortranVariableOpInterface>]> {
   let summary = "declare a variable and produce an SSA value that can be used as a variable in HLFIR operations";
 
   let description = [{
     Tie the properties of a Fortran variable to an address. The properties
     include bounds, length parameters, and Fortran attributes.
 
     The arguments are the same as for fir.declare.