[flang][driver] Add support for generating LLVM bytecode files

[awarzynski]

Summary

Support for generating LLVM BC files is added in Flang's compiler and
frontend drivers. This requires the BitcodeWriterPass pass to be run
on the input LLVM IR module and is implemented as a dedicated frontend
aciton. The new functionality as seen by the user (compiler driver):

flang-new -c -emit-llvm file.90

or (frontend driver):

flang-new -fc1 -emit-llvm-bc file.f90

The new behaviour is consistent with clang and clang -cc1.

[rovka]

Why not use the BackendAction for this? There seems to be a lot of shared code, up until the point where you create and use the pass manager (and in the future, when the backend switches to the new pass manager, there will be even more shared code).

flang/lib/Frontend/FrontendActions.cpp

483

Nit: I think you can move these closer to their first use.

flang/test/CMakeLists.txt

58

Were you going to add a test that uses this?

[awarzynski]

Add missing test

[awarzynski]

Move code a bit, add comments

flang/lib/Frontend/FrontendActions.cpp

483

Thanks, I thought that I _did_ move it :)

flang/test/CMakeLists.txt

58

Sorry, forgot to add in the original revision. Should be there now.

[awarzynski]

Thanks for taking a look Diana!

Why not use the BackendAction for this?

This action only requires the middle-end in LLVM :) The BackendAction will use the backend, but that's not needed here.

There seems to be a lot of shared code, up until the point where you create and use the pass manager

This is the bit that's shared:

CompilerInstance &ci = this->instance();
// Generate an LLVM module if it's not already present (it will already be
// present if the input file is an LLVM IR/BC file).
if (!llvmModule)
  GenerateLLVMIR();

// Create and configure `Target`
std::string error;
std::string theTriple = llvmModule->getTargetTriple();
const llvm::Target *theTarget =
    llvm::TargetRegistry::lookupTarget(theTriple, error);
assert(theTarget && "Failed to create Target");

// Create and configure `TargetMachine`
std::unique_ptr<llvm::TargetMachine> TM;

TM.reset(theTarget->createTargetMachine(theTriple, /*CPU=*/"",
    /*Features=*/"", llvm::TargetOptions(), llvm::None));
assert(TM && "Failed to create TargetMachine");
llvmModule->setDataLayout(TM->createDataLayout());

I wouldn't say it's "a lot", but probably enough for a dedicated method. I've been conservative with regard to sharing code as I anticipate things to change in the future (I expect -O{0|1|2|3|s|z} to complicate the logic a bit).

(and in the future, when the backend switches to the new pass manager, there will be even more shared code).

I'm not sure about the timelines for this. And even then, the logic might be quite different (again, middle-end vs back-end).

[rovka]

In D123211#3433059, @awarzynski wrote:

Thanks for taking a look Diana!

Why not use the BackendAction for this?

This action only requires the middle-end in LLVM :) The BackendAction will use the backend, but that's not needed here.

Is there actually a significant difference, besides the naming (which is easy to change)? AFAICT the BackendAction isn't initializing anything backend-related except very close to where it's using it, so that can happen inside a switch/if branch.

There seems to be a lot of shared code, up until the point where you create and use the pass manager

This is the bit that's shared:

CompilerInstance &ci = this->instance();
// Generate an LLVM module if it's not already present (it will already be
// present if the input file is an LLVM IR/BC file).
if (!llvmModule)
  GenerateLLVMIR();

// Create and configure `Target`
std::string error;
std::string theTriple = llvmModule->getTargetTriple();
const llvm::Target *theTarget =
    llvm::TargetRegistry::lookupTarget(theTriple, error);
assert(theTarget && "Failed to create Target");

// Create and configure `TargetMachine`
std::unique_ptr<llvm::TargetMachine> TM;

TM.reset(theTarget->createTargetMachine(theTriple, /*CPU=*/"",
    /*Features=*/"", llvm::TargetOptions(), llvm::None));
assert(TM && "Failed to create TargetMachine");
llvmModule->setDataLayout(TM->createDataLayout());

I wouldn't say it's "a lot", but probably enough for a dedicated method. I've been conservative with regard to sharing code as I anticipate things to change in the future (I expect -O{0|1|2|3|s|z} to complicate the logic a bit).

I was thinking also about the code for generating the output file, which can be folded into the switch from BackendAction. If you consider that too, it becomes a very large percentage of EmitLLVMBitcodeAction::ExecuteAction that can be shared.

(and in the future, when the backend switches to the new pass manager, there will be even more shared code).

I'm not sure about the timelines for this. And even then, the logic might be quite different (again, middle-end vs back-end).

Ok. IMO the template method pattern would work well here (or less formally, just a simple switch to the same effect), but I can understand if you think it's premature to go that route.
No other objections from my side, thanks :)

[ekieri]

One nit/question inline, otherwise LGTM.

flang/lib/Frontend/FrontendActions.cpp

491

Is there a reason why use TM.reset instead of initialising TM like you do with os below?

[awarzynski]

In D123211#3435421, @rovka wrote:

Is there actually a significant difference, besides the naming (which is easy to change)? AFAICT the BackendAction isn't initializing anything backend-related except very close to where it's using it, so that can happen inside a switch/if branch.

Currently the driver does the bare minimum to generate machine code, hence in practice both actions are near identical. I expect this to change, but I might be wrong :)

I was thinking also about the code for generating the output file, which can be folded into the switch from BackendAction. If you consider that too, it becomes a very large percentage of EmitLLVMBitcodeAction::ExecuteAction that can be shared.

Ack!

Ok. IMO the template method pattern would work well here (or less formally, just a simple switch to the same effect), but I can understand if you think it's premature to go that route.

Definitely not objecting code re-use! :) But I would like to wait for a few patches for optimisation pipelines to land first. And if anyone feels differently and sends a patch, I'd be alright with that.

flang/lib/Frontend/FrontendActions.cpp

491

Good question!

Note that createTargetMachine that I use below returns a plain pointer. createDefaultOutputFile that I use for initialising os below returns std::unique_ptr<raw_pwrite_stream>. IIUC, I can only reset a unique_ptr (like TM) with a plain pointer.

Have I missed anything?

[ekieri]

flang/lib/Frontend/FrontendActions.cpp

491

Well, I had missed that. Thanks! Let's see if I got it right this time.

So unique_ptr has an _explicit_ constructor taking a raw pointer (constructor (2)). So as you say (if I interpreted you correctly),

std::unique_ptr<llvm::TargetMachine> TM = theTarget->createTargetMachine(...);

does not work, as it requires an implicit conversion from raw to unique pointer. But constructor syntax should (and does for me) work:

std::unique_ptr<llvm::TargetMachine> TM(theTarget->createTargetMachine(...));

as this makes the conversion explicit. Does this make sense, or did I miss something more?

[awarzynski]

flang/lib/Frontend/FrontendActions.cpp

491

Does this make sense, or did I miss something more?

Yes, I'm the one who missed something here :) Many thanks for pointing this out!

I convinced myself that I checked this, but clearly I didn't. And I confused the copy-assignment with a proper constructor. Every day is a school day!

I'll merge this shortly and I will incorporate your suggestion. Thanks for your patience going over this with me :)

[ekieri]

flang/lib/Frontend/FrontendActions.cpp

491

Well, thank you! I also learned something new.

clang/include/clang/Driver/Options.td

 def emit_module_interface : Flag<["-"], "emit-module-interface">,
   HelpText<"Generate pre-compiled module file from a C++ module interface">;
 def emit_header_module : Flag<["-"], "emit-header-module">,
   HelpText<"Generate pre-compiled module file from a set of header files">;
 def emit_header_unit : Flag<["-"], "emit-header-unit">,
   HelpText<"Generate C++20 header units from header files">;
 def emit_pch : Flag<["-"], "emit-pch">,
   HelpText<"Generate pre-compiled header file">;
-def emit_llvm_bc : Flag<["-"], "emit-llvm-bc">,
-  HelpText<"Build ASTs then convert to LLVM, emit .bc file">;
 def emit_llvm_only : Flag<["-"], "emit-llvm-only">,
   HelpText<"Build ASTs and convert to LLVM, discarding output">;
 def emit_codegen_only : Flag<["-"], "emit-codegen-only">,
   HelpText<"Generate machine code, but discard output">;
 def rewrite_test : Flag<["-"], "rewrite-test">,
   HelpText<"Rewriter playground">;
 def rewrite_macros : Flag<["-"], "rewrite-macros">,
   HelpText<"Expand macros without full preprocessing">;

 
 let Flags = [CC1Option, FC1Option, NoDriverOption] in {
 let Group = Action_Group in {
 
 def emit_obj : Flag<["-"], "emit-obj">,
   HelpText<"Emit native object files">;
 def init_only : Flag<["-"], "init-only">,
   HelpText<"Only execute frontend initialization">;
+def emit_llvm_bc : Flag<["-"], "emit-llvm-bc">,
+  HelpText<"Build ASTs then convert to LLVM, emit .bc file">;
 
 } // let Group = Action_Group
 
 def load : Separate<["-"], "load">, MetaVarName<"<dsopath>">,
   HelpText<"Load the named plugin (dynamic shared object)">;
 def plugin : Separate<["-"], "plugin">, MetaVarName<"<name>">,
   HelpText<"Use the named plugin action instead of the default action (use \"help\" to list available options)">;
 

flang/include/flang/Frontend/FrontendActions.h

 class EmitMLIRAction : public CodeGenAction {
   void ExecuteAction() override;
 };
 
 class EmitLLVMAction : public CodeGenAction {
   void ExecuteAction() override;
 };
 
+class EmitLLVMBitcodeAction : public CodeGenAction {
+  void ExecuteAction() override;
+};
+
 class BackendAction : public CodeGenAction {
 public:
   enum class BackendActionTy {
     Backend_EmitAssembly, ///< Emit native assembly files
     Backend_EmitObj ///< Emit native object files
   };
 
   BackendAction(BackendActionTy act) : action{act} {};

flang/include/flang/Frontend/FrontendOptions.h

enum ActionKind {
   ParseSyntaxOnly,
 
   /// Emit a .mlir file
   EmitMLIR,
 
   /// Emit an .ll file
   EmitLLVM,
 
+  /// Emit a .bc file
+  EmitLLVMBitcode,
+
   /// Emit a .o file.
   EmitObj,
 
   /// Emit a .s file.
   EmitAssembly,
 
   /// Parse, unparse the parse-tree and output a Fortran source file
   DebugUnparse,

flang/lib/Frontend/CMakeLists.txt

add_flang_library(flangFrontend
   FortranLower
   clangBasic
   clangDriver
   FIRDialect
   FIRSupport
   FIRBuilder
   FIRCodeGen
   FIRTransforms
+  LLVMPasses
   MLIRTransforms
   MLIRLLVMToLLVMIRTranslation
   MLIRSCFToControlFlow
   ${dialect_libs}
 
   LINK_COMPONENTS
   Analysis
   Option
   Support
   Target
   FrontendOpenACC
   FrontendOpenMP
 )

flang/lib/Frontend/CompilerInvocation.cpp

case clang::driver::options::OPT_fsyntax_only:
       opts.programAction = ParseSyntaxOnly;
       break;
     case clang::driver::options::OPT_emit_mlir:
       opts.programAction = EmitMLIR;
       break;
     case clang::driver::options::OPT_emit_llvm:
       opts.programAction = EmitLLVM;
       break;
+    case clang::driver::options::OPT_emit_llvm_bc:
+      opts.programAction = EmitLLVMBitcode;
+      break;
     case clang::driver::options::OPT_emit_obj:
       opts.programAction = EmitObj;
       break;
     case clang::driver::options::OPT_S:
       opts.programAction = EmitAssembly;
       break;
     case clang::driver::options::OPT_fdebug_unparse:
       opts.programAction = DebugUnparse;

flang/lib/Frontend/FrontendActions.cpp

 #include "flang/Semantics/unparse-with-symbols.h"
 
 #include "mlir/IR/Dialect.h"
 #include "mlir/Pass/PassManager.h"
 #include "mlir/Target/LLVMIR/ModuleTranslation.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/Analysis/TargetTransformInfo.h"
+#include "llvm/Bitcode/BitcodeWriterPass.h"
 #include "llvm/IR/LegacyPassManager.h"
 #include "llvm/MC/TargetRegistry.h"
 #include "llvm/Passes/PassBuilder.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Target/TargetMachine.h"
 #include <clang/Basic/Diagnostic.h>
 #include <memory>
 
if (!os) {
     unsigned diagID = ci.diagnostics().getCustomDiagID(
         clang::DiagnosticsEngine::Error, "failed to create the output file");
     ci.diagnostics().Report(diagID);
     return;
   }
   llvmModule->print(*os, /*AssemblyAnnotationWriter=*/nullptr);
 }
 
+void EmitLLVMBitcodeAction::ExecuteAction() {
+  CompilerInstance &ci = this->instance();
+  // Generate an LLVM module if it's not already present (it will already be
+  // present if the input file is an LLVM IR/BC file).
+  if (!llvmModule)
+    GenerateLLVMIR();
+
+  // Create and configure `Target`
+  std::string error;
+  std::string theTriple = llvmModule->getTargetTriple();
+  const llvm::Target *theTarget =
+      llvm::TargetRegistry::lookupTarget(theTriple, error);
+  assert(theTarget && "Failed to create Target");
+
+  // Create and configure `TargetMachine`
+  std::unique_ptr<llvm::TargetMachine> TM(
+      theTarget->createTargetMachine(theTriple, /*CPU=*/"",
+          /*Features=*/"", llvm::TargetOptions(), llvm::None));
+  assert(TM && "Failed to create TargetMachine");
+  llvmModule->setDataLayout(TM->createDataLayout());
+
+  // Generate an output file
+  std::unique_ptr<llvm::raw_ostream> os = ci.CreateDefaultOutputFile(
+      /*Binary=*/true, /*InFile=*/GetCurrentFileOrBufferName(), "bc");
+  if (!os) {
+    unsigned diagID = ci.diagnostics().getCustomDiagID(
+        clang::DiagnosticsEngine::Error, "failed to create the output file");
+    ci.diagnostics().Report(diagID);
+    return;
+  }
+
+  // Set-up the pass manager
+  llvm::ModulePassManager MPM;
+  llvm::ModuleAnalysisManager MAM;
+  llvm::PassBuilder PB(TM.get());
+  PB.registerModuleAnalyses(MAM);
+  MPM.addPass(llvm::BitcodeWriterPass(*os));
+
+  // Run the passes
+  MPM.run(*llvmModule, MAM);
+}
+
 void EmitMLIRAction::ExecuteAction() {
   CompilerInstance &ci = this->instance();
 
   // Print the output. If a pre-defined output stream exists, dump the MLIR
   // content there.
   if (!ci.IsOutputStreamNull()) {
     mlirModule->print(ci.GetOutputStream());
     return;

flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp

static std::unique_ptr<FrontendAction> CreateFrontendBaseAction(
   case PrintPreprocessedInput:
     return std::make_unique<PrintPreprocessedAction>();
   case ParseSyntaxOnly:
     return std::make_unique<ParseSyntaxOnlyAction>();
   case EmitMLIR:
     return std::make_unique<EmitMLIRAction>();
   case EmitLLVM:
     return std::make_unique<EmitLLVMAction>();
+  case EmitLLVMBitcode:
+    return std::make_unique<EmitLLVMBitcodeAction>();
   case EmitObj:
     return std::make_unique<BackendAction>(
         BackendAction::BackendActionTy::Backend_EmitObj);
   case EmitAssembly:
     return std::make_unique<BackendAction>(
         BackendAction::BackendActionTy::Backend_EmitAssembly);
   case DebugUnparse:
     return std::make_unique<DebugUnparseAction>();

flang/test/CMakeLists.txt

set(FLANG_TEST_DEPENDS
   llvm-config
   FileCheck
   count
   not
   module_files
   fir-opt
   tco
   bbc
+  llvm-dis
   llvm-objdump
   split-file
 )
 
 if (FLANG_INCLUDE_TESTS)
   if (FLANG_GTEST_AVAIL)
     list(APPEND FLANG_TEST_DEPENDS FlangUnitTests)
   endif()

flang/test/Driver/driver-help.f90

 !-------------------------------------------------------------
 ! EXPECTED OUTPUT FOR FLANG FRONTEND DRIVER (flang -fc1)
 !-------------------------------------------------------------
 ! HELP-FC1:USAGE: flang
 ! HELP-FC1-EMPTY:
 ! HELP-FC1-NEXT:OPTIONS:
 ! HELP-FC1-NEXT: -cpp                   Enable predefined and command line preprocessor macros
 ! HELP-FC1-NEXT: -D <macro>=<value>     Define <macro> to <value> (or 1 if <value> omitted)
+! HELP-FC1-NEXT: -emit-llvm-bc          Build ASTs then convert to LLVM, emit .bc file
 ! HELP-FC1-NEXT: -emit-llvm Use the LLVM representation for assembler and object files
 ! HELP-FC1-NEXT: -emit-mlir Build the parse tree, then lower it to MLIR
 ! HELP-FC1-NEXT: -emit-obj Emit native object files
 ! HELP-FC1-NEXT: -E                     Only run the preprocessor
 ! HELP-FC1-NEXT: -falternative-parameter-statement
 ! HELP-FC1-NEXT: Enable the old style PARAMETER statement
 ! HELP-FC1-NEXT: -fbackslash            Specify that backslash in string introduces an escape character
 ! HELP-FC1-NEXT: -fdebug-dump-all       Dump symbols and the parse tree after the semantic checks

flang/test/Driver/emit-llvm-bc.f90

+! Test the options for generating LLVM byte-code `-emit-llvm-bc` option
+
+!-------------
+! RUN COMMANDS
+!-------------
+! RUN: %flang -emit-llvm -c %s -o - | llvm-dis -o - | FileCheck %s
+! RUN: %flang_fc1 -emit-llvm-bc %s -o - | llvm-dis -o - | FileCheck %s
+
+!----------------
+! EXPECTED OUTPUT
+!----------------
+! CHECK: define void @_QQmain()
+! CHECK-NEXT:  ret void
+! CHECK-NEXT: }
+
+!------
+! INPUT
+!------
+end program