[flang]Zero Initialize simple types

[Leporacanthicus]

Summary

Instead of filling uninitialized global variables with "undef",
initialize them with 0. Only for Integer, Float or Logical type
variables. Complex, user defined data structures, arrays, etc
are not supported at this point.

This patch fixes the main problem of
https://github.com/llvm/llvm-project/issues/62432

[jeanPerier]

Thanks for working on this!

Note that there is a fir::ZeroOp that is intended to create some zero initialized data regardless of the type, but it currently is a TODO in codegen for aggregate/array types (That is actually the fir.zero_init). I think a zeroinitialzer operation may be required in LLVM MLIR dialect (like for the poison/undef op), so that we can propagate fir::ZeroOp into an LLVM zeroinitializer.

[Leporacanthicus]

In D149877#4321929, @jeanPerier wrote:

Thanks for working on this!

Note that there is a fir::ZeroOp that is intended to create some zero initialized data regardless of the type, but it currently is a TODO in codegen for aggregate/array types (That is actually the fir.zero_init). I think a zeroinitialzer operation may be required in LLVM MLIR dialect (like for the poison/undef op), so that we can propagate fir::ZeroOp into an LLVM zeroinitializer.

Yes, the "createNullConstant" creates a fir::ZeroOp, this is why I also had to make a minor change to the code dealing with that operation (because we want to retain the original logical, rather than use integer when the original type is a logical. Could probably do with a synonym or rename, but it does produce the correct operation. [I think LLVM has a similar function, and it's used to create all sorts of zero-filled types, if I recall correctly]. I guess we could just create the ZeroOp directly, rather than calling a function - I'll fix that now.

It would indeed be great to have a zeroinitializer that goes all the way through MLIR. There is a thread on that in Discourse:
https://discourse.llvm.org/t/zero-initialization-for-globals-with-common-linkage/1762
As far as I can tell, nobody has implemented this. I have made a comment, and I will see if I can do that - I don't know if it's much work.

Filling something with zeros does make it a LLVM zeroinitializer attribute. So for example, if I do complex c = (0, 0) that becomes c = global {float, float} zeroinitializer in LLVM-IR, even tho' it's a whole bunch of operations in FIR.

One of the reasons I stuck to "only basic types" is that the code is incomplete for other types. If we had a mlir::LLVM::ZeroOp (or whatever the name should be), then that could be directly translated to LLVM zeroinitializer too.

[schweitz]

In D149877#4322087, @Leporacanthicus wrote:

In D149877#4321929, @jeanPerier wrote:

Thanks for working on this!

Note that there is a fir::ZeroOp that is intended to create some zero initialized data regardless of the type, but it currently is a TODO in codegen for aggregate/array types (That is actually the fir.zero_init). I think a zeroinitialzer operation may be required in LLVM MLIR dialect (like for the poison/undef op), so that we can propagate fir::ZeroOp into an LLVM zeroinitializer.

Yes, the "createNullConstant" creates a fir::ZeroOp, this is why I also had to make a minor change to the code dealing with that operation (because we want to retain the original logical, rather than use integer when the original type is a logical. Could probably do with a synonym or rename, but it does produce the correct operation. [I think LLVM has a similar function, and it's used to create all sorts of zero-filled types, if I recall correctly]. I guess we could just create the ZeroOp directly, rather than calling a function - I'll fix that now.

It would indeed be great to have a zeroinitializer that goes all the way through MLIR. There is a thread on that in Discourse:
https://discourse.llvm.org/t/zero-initialization-for-globals-with-common-linkage/1762
As far as I can tell, nobody has implemented this. I have made a comment, and I will see if I can do that - I don't know if it's much work.

Filling something with zeros does make it a LLVM zeroinitializer attribute. So for example, if I do complex c = (0, 0) that becomes c = global {float, float} zeroinitializer in LLVM-IR, even tho' it's a whole bunch of operations in FIR.

One of the reasons I stuck to "only basic types" is that the code is incomplete for other types. If we had a mlir::LLVM::ZeroOp (or whatever the name should be), then that could be directly translated to LLVM zeroinitializer too.

It would be really great to get "all zero" all the way from FIR to LLVM's zero_initializer for any sort of type. Semi-related is the quadratic behavior of converting large blobs (e.g., an array of a few million tuples of type {f64, f32, i64, i8*}) of data to LLVM via the LLVM-IR dialect conversion. Various mitigations have been tried, but it's still an area that needs some attention on the MLIR side as well.

[Leporacanthicus]

Just create a ZeroOp instead of calling createNullConstant.

[jeanPerier]

Thanks, this is an improvement on the current situation (and thanks for the link to the thread).
Can you add a quick line in flang/docs/Extensions.md under "Extensions, deletions, and legacy features supported by default" that saved integer, logical, and real scalars are zero initialized?

I think we could use mlir attributes to support zero initialization of all intrinsic types/intrinsic arrays too (but that can be done independently).

Derived type can wait for zeroinitializer, the reliance on them being zero initialized is probably less common and the codegen implementation would be cumbersome/yields big compile time for derived type arrays due to the poor llvm.insert folding performance.

[Leporacanthicus]

Update docs to let people know we changed to zero initialize some
globals.

flang/docs/Extensions.md

 * The argument to `RANDOM_NUMBER` may not be an assumed-size array.
 
 ## Extensions, deletions, and legacy features supported by default
 
 * Tabs in source
 * `<>` as synonym for `.NE.` and `/=`
 * `$` and `@` as legal characters in names
 * Initialization in type declaration statements using `/values/`
+* Saved integer, logical and real scalars are zero initialized.
 * Kind specification with `*`, e.g. `REAL*4`
 * `DOUBLE COMPLEX` as a synonym for `COMPLEX(KIND(0.D0))` --
   but not when spelled `TYPE(DOUBLECOMPLEX)`.
 * Signed complex literal constants
 * DEC `STRUCTURE`, `RECORD`, with '%FILL'; but `UNION`, and `MAP`
   are not yet supported throughout compilation, and elicit a
   "not yet implemented" message.
 * Structure field access with `.field`

flang/lib/Lower/ConvertVariable.cpp

if (details->init()) {
             builder.create<fir::HasValueOp>(loc, castTo);
           });
     }
   } else if (sym.has<Fortran::semantics::CommonBlockDetails>()) {
     mlir::emitError(loc, "COMMON symbol processed elsewhere");
   } else {
     TODO(loc, "global"); // Procedure pointer or something else
   }
-  // Creates undefined initializer for globals without initializers
+  // Creates zero or undefined initializer for globals without initializers
+  // Zero initializer is used for "simple types" (integer, real and logical),
+  // undefined is used for types aside from those types.
   if (!globalIsInitialized(global)) {
     // TODO: Is it really required to add the undef init if the Public
     // visibility is set ? We need to make sure the global is not optimized out
     // by LLVM if unused in the current compilation unit, but at least for
     // BIND(C) variables, an initial value may be given in another compilation
     // unit (on the C side), and setting an undef init here creates linkage
     // conflicts.
     if (sym.attrs().test(Fortran::semantics::Attr::BIND_C))
       TODO(loc, "BIND(C) module variable linkage");
     Fortran::lower::createGlobalInitialization(
         builder, global, [&](fir::FirOpBuilder &builder) {
-          builder.create<fir::HasValueOp>(
-              loc, builder.create<fir::UndefOp>(loc, symTy));
+          mlir::Value initValue;
+          if (symTy.isa<mlir::IntegerType, mlir::FloatType, fir::LogicalType>())
+            initValue = builder.create<fir::ZeroOp>(loc, symTy);
+          else
+            initValue = builder.create<fir::UndefOp>(loc, symTy);
+          builder.create<fir::HasValueOp>(loc, initValue);
         });
   }
   // Set public visibility to prevent global definition to be optimized out
   // even if they have no initializer and are unused in this compilation unit.
   global.setVisibility(mlir::SymbolTable::Visibility::Public);
   return global;
 }
 

flang/lib/Optimizer/CodeGen/CodeGen.cpp

struct ZeroOpConversion : public FIROpConversion<fir::ZeroOp> {
   mlir::LogicalResult
   matchAndRewrite(fir::ZeroOp zero, OpAdaptor,
                   mlir::ConversionPatternRewriter &rewriter) const override {
     mlir::Type ty = convertType(zero.getType());
     if (ty.isa<mlir::LLVM::LLVMPointerType>()) {
       rewriter.replaceOpWithNewOp<mlir::LLVM::NullOp>(zero, ty);
     } else if (ty.isa<mlir::IntegerType>()) {
       rewriter.replaceOpWithNewOp<mlir::LLVM::ConstantOp>(
-          zero, ty, mlir::IntegerAttr::get(zero.getType(), 0));
+          zero, ty, mlir::IntegerAttr::get(ty, 0));
     } else if (mlir::LLVM::isCompatibleFloatingPointType(ty)) {
       rewriter.replaceOpWithNewOp<mlir::LLVM::ConstantOp>(
           zero, ty, mlir::FloatAttr::get(zero.getType(), 0.0));
     } else {
       // TODO: create ConstantAggregateZero for FIR aggregate/array types.
       return rewriter.notifyMatchFailure(
           zero,
           "conversion of fir.zero with aggregate type not implemented yet");

flang/test/Lower/target_definition.f90

 ! RUN: bbc -emit-fir %s -o - | FileCheck %s
 
 ! Test TARGET attributes on a definition of a global symbol.
 ! CHECK: fir.global @_QMtarget_modEx target : f32 {
-! CHECK:   %[[init:.*]] = fir.undefined f32
+! CHECK:   %[[init:.*]] = fir.zero_bits f32
 ! CHECK:   fir.has_value %[[init]] : f32
 ! CHECK: }
 
 module target_mod
   real, target :: x
 end module target_mod