llvm-project/flang/lib/Frontend/FrontendActions.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

788 lines
27 KiB
C++
Raw Normal View History

[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
//===--- FrontendActions.cpp ----------------------------------------------===//
//
// 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
//
//===----------------------------------------------------------------------===//
//
// Coding style: https://mlir.llvm.org/getting_started/DeveloperGuide/
//
//===----------------------------------------------------------------------===//
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
#include "flang/Frontend/FrontendActions.h"
#include "flang/Common/default-kinds.h"
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
#include "flang/Frontend/CompilerInstance.h"
#include "flang/Frontend/FrontendOptions.h"
[flang][driver] Add support for `-cpp/-nocpp` This patch adds support for the `-cpp` and `-nocpp` flags. The implemented semantics match f18 (i.e. the "throwaway" driver), but are different to gfortran. In Flang the preprocessor is always run. Instead, `-cpp/-nocpp` are used to control whether predefined and command-line preprocessor macro definitions are enabled or not. In practice this is sufficient to model gfortran`s `-cpp/-nocpp`. In the absence of `-cpp/-nocpp`, the driver will use the extension of the input file to decide whether to include the standard macro predefinitions. gfortran's documentation [1] was used to decide which file extension to use for this. The logic mentioned above was added in FrontendAction::BeginSourceFile. That's relatively late in the driver set-up, but this roughly where the name of the input file becomes available. The logic for deciding between fixed and free form works in a similar way and was also moved to FrontendAction::BeginSourceFile for consistency (and to reduce code-duplication). The `-cpp/-nocpp` flags are respected also when the input is read from stdin. This is different to: * gfortran (behaves as if `-cpp` was used) * f18 (behaves as if `-nocpp` was used) Starting with this patch, file extensions are significant and some test files had to be renamed to reflect that. Where possible, preprocessor tests were updated so that they can be shared between `f18` and `flang-new`. This was implemented on top of adding new test for `-cpp/-nocpp`. [1] https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D99292
2021-04-07 11:42:37 +00:00
#include "flang/Frontend/PreprocessorOptions.h"
#include "flang/Lower/Bridge.h"
#include "flang/Lower/PFTBuilder.h"
#include "flang/Lower/Support/Verifier.h"
#include "flang/Optimizer/Support/FIRContext.h"
#include "flang/Optimizer/Support/InitFIR.h"
#include "flang/Optimizer/Support/KindMapping.h"
#include "flang/Optimizer/Support/Utils.h"
#include "flang/Parser/dump-parse-tree.h"
#include "flang/Parser/parsing.h"
#include "flang/Parser/provenance.h"
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
#include "flang/Parser/source.h"
#include "flang/Parser/unparse.h"
#include "flang/Semantics/runtime-type-info.h"
#include "flang/Semantics/semantics.h"
#include "flang/Semantics/unparse-with-symbols.h"
#include "mlir/IR/Dialect.h"
#include "mlir/Parser/Parser.h"
#include "mlir/Pass/PassManager.h"
#include "mlir/Target/LLVMIR/ModuleTranslation.h"
#include "clang/Basic/Diagnostic.h"
[flang][driver] Define the default frontend driver triple *SUMMARY* Currently, the frontend driver assumes that a target triple is either: * provided by the frontend itself (e.g. when lowering and generating code), * specified through the `-triple/-target` command line flags. If `-triple/-target` is not used, the frontend will simply use the host triple. This is going to be insufficient when e.g. consuming an LLVM IR file that has no triple specified (reading LLVM files is WIP, see D124667). We shouldn't require the triple to be specified via the command line in such situation. Instead, the frontend driver should contain a good default, e.g. the host triple. This patch updates Flang's `CompilerInvocation` to do just that, i.e. defines its default target triple. Similarly to Clang: * the default `CompilerInvocation` triple is set as the host triple, * the value specified with `-triple` takes precedence over the frontend driver default and the current module triple, * the frontend driver default takes precedence over the module triple. *TESTS* This change requires 2 unit tests to be updated. That's because relevant frontend actions are updated to assume that there's always a valid triple available in the current `CompilerInvocation`. This update is required because the unit tests bypass the regular `CompilerInvocation` set-up (in particular, they don't call `CompilerInvocation::CreateFromArgs`). I've also taken the liberty to disable the pre-precossor formatting in the affected unit tests as well (it is not required). No new tests are added. As `flang-new -fc1` does not support consuming LLVM IR files just yet, it is not possible to compile an LLVM IR file without a triple. More specifically, atm all LLVM IR files are generated and stored internally and the driver makes sure that these contain a valid target triple. This is about to change in D124667 (which adds support for reading LLVM IR/BC files) and that's where tests for exercising the default frontend driver triple will be added. *WHAT DOES CLANG DO?* For reference, the default target triple for Clang's `CompilerInvocation` is set through option marshalling infra [1] in Options.td. Please check the definition of the `-triple` flag: ``` def triple : Separate<["-"], "triple">, HelpText<"Specify target triple (e.g. i686-apple-darwin9)">, MarshallingInfoString<TargetOpts<"Triple">, "llvm::Triple::normalize(llvm::sys::getDefaultTargetTriple())">, AlwaysEmit, Normalizer<"normalizeTriple">; ``` Ideally, we should re-use the marshalling infra in Flang. [1] https://clang.llvm.org/docs/InternalsManual.html#option-marshalling-infrastructure Differential Revision: https://reviews.llvm.org/D124664
2022-04-28 14:12:32 +00:00
#include "clang/Basic/DiagnosticFrontend.h"
#include "llvm/ADT/StringRef.h"
[flang][driver] Add support for -S and implement -c/-emit-obj This patch adds support for: * `-S` in Flang's compiler and frontend drivers, and implements: * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler driver (this is consistent with Clang). (these options were already available before, but only as placeholders). The semantics of these options in Clang and Flang are identical. The `EmitObjAction` frontend action is renamed as `BackendAction`. This new name more accurately reflects the fact that this action will primarily run the code-gen/backend pipeline in LLVM. It also makes more sense as an action implementing both `-emit-obj` and `-S` (originally, it was just `-emit-obj`). `tripleName` from FirContext.cpp is deleted and, when a target triple is required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used instead. In practice, this means that `fir.triple` is replaced with `llvm.target_triple`. The former was effectively ignored. The latter is used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's embedded in the generated LLVM IR module). The driver can then re-use it when configuring the backend. With this change, the LLVM IR files generated by e.g. `tco` will from now on contain the correct target triple. The code-gen.f90 test is replaced with code-gen-x86.f90 and code-gen-aarch64.f90. With 2 seperate files we can verify that `--target` is correctly taken into account. LIT configuration is updated to enable e.g.: ``` ! REQUIRES: aarch64-registered-target ``` Differential Revision: https://reviews.llvm.org/D120568
2022-02-24 17:34:27 +00:00
#include "llvm/Analysis/TargetLibraryInfo.h"
#include "llvm/Analysis/TargetTransformInfo.h"
#include "llvm/Bitcode/BitcodeWriterPass.h"
[flang][driver] Add support for -S and implement -c/-emit-obj This patch adds support for: * `-S` in Flang's compiler and frontend drivers, and implements: * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler driver (this is consistent with Clang). (these options were already available before, but only as placeholders). The semantics of these options in Clang and Flang are identical. The `EmitObjAction` frontend action is renamed as `BackendAction`. This new name more accurately reflects the fact that this action will primarily run the code-gen/backend pipeline in LLVM. It also makes more sense as an action implementing both `-emit-obj` and `-S` (originally, it was just `-emit-obj`). `tripleName` from FirContext.cpp is deleted and, when a target triple is required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used instead. In practice, this means that `fir.triple` is replaced with `llvm.target_triple`. The former was effectively ignored. The latter is used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's embedded in the generated LLVM IR module). The driver can then re-use it when configuring the backend. With this change, the LLVM IR files generated by e.g. `tco` will from now on contain the correct target triple. The code-gen.f90 test is replaced with code-gen-x86.f90 and code-gen-aarch64.f90. With 2 seperate files we can verify that `--target` is correctly taken into account. LIT configuration is updated to enable e.g.: ``` ! REQUIRES: aarch64-registered-target ``` Differential Revision: https://reviews.llvm.org/D120568
2022-02-24 17:34:27 +00:00
#include "llvm/IR/LegacyPassManager.h"
#include "llvm/IR/Verifier.h"
#include "llvm/IRReader/IRReader.h"
[flang][driver] Add support for -S and implement -c/-emit-obj This patch adds support for: * `-S` in Flang's compiler and frontend drivers, and implements: * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler driver (this is consistent with Clang). (these options were already available before, but only as placeholders). The semantics of these options in Clang and Flang are identical. The `EmitObjAction` frontend action is renamed as `BackendAction`. This new name more accurately reflects the fact that this action will primarily run the code-gen/backend pipeline in LLVM. It also makes more sense as an action implementing both `-emit-obj` and `-S` (originally, it was just `-emit-obj`). `tripleName` from FirContext.cpp is deleted and, when a target triple is required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used instead. In practice, this means that `fir.triple` is replaced with `llvm.target_triple`. The former was effectively ignored. The latter is used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's embedded in the generated LLVM IR module). The driver can then re-use it when configuring the backend. With this change, the LLVM IR files generated by e.g. `tco` will from now on contain the correct target triple. The code-gen.f90 test is replaced with code-gen-x86.f90 and code-gen-aarch64.f90. With 2 seperate files we can verify that `--target` is correctly taken into account. LIT configuration is updated to enable e.g.: ``` ! REQUIRES: aarch64-registered-target ``` Differential Revision: https://reviews.llvm.org/D120568
2022-02-24 17:34:27 +00:00
#include "llvm/MC/TargetRegistry.h"
#include "llvm/Passes/PassBuilder.h"
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
#include "llvm/Passes/StandardInstrumentations.h"
#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/SourceMgr.h"
[flang][driver] Add support for -S and implement -c/-emit-obj This patch adds support for: * `-S` in Flang's compiler and frontend drivers, and implements: * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler driver (this is consistent with Clang). (these options were already available before, but only as placeholders). The semantics of these options in Clang and Flang are identical. The `EmitObjAction` frontend action is renamed as `BackendAction`. This new name more accurately reflects the fact that this action will primarily run the code-gen/backend pipeline in LLVM. It also makes more sense as an action implementing both `-emit-obj` and `-S` (originally, it was just `-emit-obj`). `tripleName` from FirContext.cpp is deleted and, when a target triple is required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used instead. In practice, this means that `fir.triple` is replaced with `llvm.target_triple`. The former was effectively ignored. The latter is used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's embedded in the generated LLVM IR module). The driver can then re-use it when configuring the backend. With this change, the LLVM IR files generated by e.g. `tco` will from now on contain the correct target triple. The code-gen.f90 test is replaced with code-gen-x86.f90 and code-gen-aarch64.f90. With 2 seperate files we can verify that `--target` is correctly taken into account. LIT configuration is updated to enable e.g.: ``` ! REQUIRES: aarch64-registered-target ``` Differential Revision: https://reviews.llvm.org/D120568
2022-02-24 17:34:27 +00:00
#include "llvm/Target/TargetMachine.h"
#include <memory>
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
using namespace Fortran::frontend;
//===----------------------------------------------------------------------===//
// Custom BeginSourceFileAction
//===----------------------------------------------------------------------===//
bool PrescanAction::beginSourceFileAction() { return runPrescan(); }
[flang][driver] Add debug options not requiring semantic checks This patch adds two debugging options in the new Flang driver (flang-new): *fdebug-unparse-no-sema *fdebug-dump-parse-tree-no-sema Each of these options combines two options from the "throwaway" driver (left: f18, right: flang-new): * `-fdebug-uparse -fdebug-no-semantics` --> `-fdebug-unparse-no-sema` * `-fdebug-dump-parse-tree -fdebug-no-semantics` --> `-fdebug-dump-parse-tree-no-sema` There are no plans to implement `-fdebug-no-semantics` in the new driver. Such option would be too powerful. Also, it would only make sense when combined with specific frontend actions (`-fdebug-unparse` and `-fdebug-dump-parse-tree`). Instead, this patch adds 2 specialised options listed above. Each of these is implemented through a dedicated FrontendAction (also added). The new frontend actions are implemented in terms of a new abstract base action: `PrescanAndSemaAction`. This new base class was required so that we can have finer control over what steps within the frontend are executed: * `PrescanAction`: run the _prescanner_ * `PrescanAndSemaAction`: run the _prescanner_ and the _parser_ (new in this patch) * `PrescanAndSemaAction`: run the _prescanner_, _parser_ and run the _semantic checks_ This patch introduces `PrescanAndParseAction::BeginSourceFileAction`. Apart from the semantic checks removed at the end, it is similar to `PrescanAndSemaAction::BeginSourceFileAction`. Differential Revision: https://reviews.llvm.org/D99645
2021-03-30 10:35:42 +00:00
bool PrescanAndParseAction::beginSourceFileAction() {
return runPrescan() && runParse();
[flang][driver] Add debug options not requiring semantic checks This patch adds two debugging options in the new Flang driver (flang-new): *fdebug-unparse-no-sema *fdebug-dump-parse-tree-no-sema Each of these options combines two options from the "throwaway" driver (left: f18, right: flang-new): * `-fdebug-uparse -fdebug-no-semantics` --> `-fdebug-unparse-no-sema` * `-fdebug-dump-parse-tree -fdebug-no-semantics` --> `-fdebug-dump-parse-tree-no-sema` There are no plans to implement `-fdebug-no-semantics` in the new driver. Such option would be too powerful. Also, it would only make sense when combined with specific frontend actions (`-fdebug-unparse` and `-fdebug-dump-parse-tree`). Instead, this patch adds 2 specialised options listed above. Each of these is implemented through a dedicated FrontendAction (also added). The new frontend actions are implemented in terms of a new abstract base action: `PrescanAndSemaAction`. This new base class was required so that we can have finer control over what steps within the frontend are executed: * `PrescanAction`: run the _prescanner_ * `PrescanAndSemaAction`: run the _prescanner_ and the _parser_ (new in this patch) * `PrescanAndSemaAction`: run the _prescanner_, _parser_ and run the _semantic checks_ This patch introduces `PrescanAndParseAction::BeginSourceFileAction`. Apart from the semantic checks removed at the end, it is similar to `PrescanAndSemaAction::BeginSourceFileAction`. Differential Revision: https://reviews.llvm.org/D99645
2021-03-30 10:35:42 +00:00
}
bool PrescanAndSemaAction::beginSourceFileAction() {
return runPrescan() && runParse() && runSemanticChecks() &&
generateRtTypeTables();
}
bool PrescanAndSemaDebugAction::beginSourceFileAction() {
// This is a "debug" action for development purposes. To facilitate this, the
// semantic checks are made to succeed unconditionally to prevent this action
// from exiting early (i.e. in the presence of semantic errors). We should
// never do this in actions intended for end-users or otherwise regular
// compiler workflows!
return runPrescan() && runParse() && (runSemanticChecks() || true) &&
(generateRtTypeTables() || true);
}
bool CodeGenAction::beginSourceFileAction() {
llvmCtx = std::make_unique<llvm::LLVMContext>();
CompilerInstance &ci = this->getInstance();
// If the input is an LLVM file, just parse it and return.
if (this->getCurrentInput().getKind().getLanguage() == Language::LLVM_IR) {
llvm::SMDiagnostic err;
llvmModule = llvm::parseIRFile(getCurrentInput().getFile(), err, *llvmCtx);
if (!llvmModule || llvm::verifyModule(*llvmModule, &llvm::errs())) {
err.print("flang-new", llvm::errs());
unsigned diagID = ci.getDiagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "Could not parse IR");
ci.getDiagnostics().Report(diagID);
return false;
}
return true;
}
// Load the MLIR dialects required by Flang
mlir::DialectRegistry registry;
mlirCtx = std::make_unique<mlir::MLIRContext>(registry);
fir::support::registerNonCodegenDialects(registry);
fir::support::loadNonCodegenDialects(*mlirCtx);
fir::support::loadDialects(*mlirCtx);
fir::support::registerLLVMTranslation(*mlirCtx);
// If the input is an MLIR file, just parse it and return.
if (this->getCurrentInput().getKind().getLanguage() == Language::MLIR) {
llvm::SourceMgr sourceMgr;
llvm::ErrorOr<std::unique_ptr<llvm::MemoryBuffer>> fileOrErr =
llvm::MemoryBuffer::getFileOrSTDIN(getCurrentInput().getFile());
sourceMgr.AddNewSourceBuffer(std::move(*fileOrErr), llvm::SMLoc());
mlir::OwningOpRef<mlir::ModuleOp> module =
mlir::parseSourceFile<mlir::ModuleOp>(sourceMgr, mlirCtx.get());
if (!module || mlir::failed(module->verifyInvariants())) {
unsigned diagID = ci.getDiagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "Could not parse FIR");
ci.getDiagnostics().Report(diagID);
return false;
}
mlirModule = std::make_unique<mlir::ModuleOp>(module.release());
return true;
}
// Otherwise, generate an MLIR module from the input Fortran source
if (getCurrentInput().getKind().getLanguage() != Language::Fortran) {
unsigned diagID = ci.getDiagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error,
"Invalid input type - expecting a Fortran file");
ci.getDiagnostics().Report(diagID);
return false;
}
bool res = runPrescan() && runParse() && runSemanticChecks() &&
generateRtTypeTables();
if (!res)
return res;
// Create a LoweringBridge
const common::IntrinsicTypeDefaultKinds &defKinds =
ci.getInvocation().getSemanticsContext().defaultKinds();
fir::KindMapping kindMap(mlirCtx.get(),
llvm::ArrayRef<fir::KindTy>{fir::fromDefaultKinds(defKinds)});
lower::LoweringBridge lb = Fortran::lower::LoweringBridge::create(
*mlirCtx, defKinds, ci.getInvocation().getSemanticsContext().intrinsics(),
ci.getParsing().allCooked(), ci.getInvocation().getTargetOpts().triple,
kindMap);
// Create a parse tree and lower it to FIR
Fortran::parser::Program &parseTree{*ci.getParsing().parseTree()};
lb.lower(parseTree, ci.getInvocation().getSemanticsContext());
mlirModule = std::make_unique<mlir::ModuleOp>(lb.getModule());
// run the default passes.
mlir::PassManager pm(mlirCtx.get(), mlir::OpPassManager::Nesting::Implicit);
pm.enableVerifier(/*verifyPasses=*/true);
pm.addPass(std::make_unique<Fortran::lower::VerifierPass>());
if (mlir::failed(pm.run(*mlirModule))) {
unsigned diagID = ci.getDiagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error,
"verification of lowering to FIR failed");
ci.getDiagnostics().Report(diagID);
return false;
}
return true;
}
//===----------------------------------------------------------------------===//
// Custom ExecuteAction
//===----------------------------------------------------------------------===//
void InputOutputTestAction::executeAction() {
CompilerInstance &ci = getInstance();
// Create a stream for errors
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
std::string buf;
llvm::raw_string_ostream errorStream{buf};
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
// Read the input file
Fortran::parser::AllSources &allSources{ci.getAllSources()};
std::string path{getCurrentFileOrBufferName()};
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
const Fortran::parser::SourceFile *sf;
if (path == "-")
sf = allSources.ReadStandardInput(errorStream);
else
sf = allSources.Open(path, errorStream, std::optional<std::string>{"."s});
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
llvm::ArrayRef<char> fileContent = sf->content();
// Output file descriptor to receive the contents of the input file.
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
std::unique_ptr<llvm::raw_ostream> os;
// Copy the contents from the input file to the output file
if (!ci.isOutputStreamNull()) {
// An output stream (outputStream_) was set earlier
ci.writeOutputStream(fileContent.data());
} else {
// No pre-set output stream - create an output file
os = ci.createDefaultOutputFile(
/*binary=*/true, getCurrentFileOrBufferName(), "txt");
[Flang][Driver] Add infrastructure for basic frontend actions and file I/O This patch introduces the dependencies required to read and manage input files provided by the command line option. It also adds the infrastructure to create and write to output files. The output is sent to either stdout or a file (specified with the `-o` flag). Separately, in order to be able to test the code for file I/O, it adds infrastructure to create frontend actions. As a basic testable example, it adds the `InputOutputTest` FrontendAction. The sole purpose of this action is to read a file from the command line and print it either to stdout or the output file. This action is run by using the `-test-io` flag also introduced in this patch (available for `flang-new` and `flang-new -fc1`). With this patch: ``` flang-new -test-io input-file.f90 ``` will read input-file.f90 and print it in the output file. The `InputOutputTest` frontend action has been introduced primarily to facilitate testing. It is hidden from users (i.e. it's only displayed with `--help-hidden`). Currently Clang doesn’t have an equivalent action. `-test-io` is used to trigger the InputOutputTest action in the Flang frontend driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1" by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to “flang-new -fc1” without `-E`. This way we make sure that the preprocessor is _not_ run in the frontend driver. This is the desired behaviour: `-test-io` should only read the input file and print it to the output stream. co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Differential Revision: https://reviews.llvm.org/D87989
2020-10-24 12:33:19 +01:00
if (!os)
return;
(*os) << fileContent.data();
}
}
void PrintPreprocessedAction::executeAction() {
std::string buf;
llvm::raw_string_ostream outForPP{buf};
// Format or dump the prescanner's output
CompilerInstance &ci = this->getInstance();
if (ci.getInvocation().getPreprocessorOpts().noReformat) {
ci.getParsing().DumpCookedChars(outForPP);
} else {
ci.getParsing().EmitPreprocessedSource(
outForPP, !ci.getInvocation().getPreprocessorOpts().noLineDirectives);
}
// Print getDiagnostics from the prescanner
ci.getParsing().messages().Emit(llvm::errs(), ci.getAllCookedSources());
[flang] Refine output file generation This patch cleans-up the file generation code in Flang's frontend driver. It improves the layering between `CompilerInstance::CreateDefaultOutputFile`, `CompilerInstance::CreateOutputFile` and their various clients. * Rename `CreateOutputFile` as `CreateOutputFileImpl` and make it private. This method is an implementation detail. * Instead of passing an `std::error_code` out parameter into `CreateOutputFileImpl`, have it return Expected<>. This is a bit shorter and idiomatic LLVM. * Make `CreateDefaultOutputFile` (which calls `CreateOutputFileImpl`) issue an error when file creation fails. The error code from `CreateOutputFileImpl` is used to generate a meaningful diagnostic message. * Remove error reporting from `PrintPreprocessedAction::ExecuteAction`. This is only for cases when output file generation fails. This is handled in `CreateDefaultOutputFile` instead (see the previous point). * Inline `AddOutputFile` into its only caller, `CreateDefaultOutputFile`. * Switch from `lvm::buffer_ostream` to `llvm::buffer_unique_ostream>` for non-seekable output streams. This simplifies the logic in the driver and was introduced for this very reason in [1] * Moke sure that the diagnostics from the prescanner when running `-E` (`PrintPreprocessedAction::ExecuteAction`) are printed before the actual output is generated. * Update comments, add test. NOTE: This patch relands [2]. As suggested by Michael Kruse in the post-commit/post-revert review, I've added the following: ``` config.errc_messages = "@LLVM_LIT_ERRC_MESSAGES@" ``` in Flang's `lit.site.cfg.py.in`. This way, `%errc_ENOENT` in output-paths.f90 gets the correct value on Windows as well as on Linux. [1] https://reviews.llvm.org/D93260 [2] fd21d1e198e381a2b9e7af1701044462b2d386cd Reviewed By: ashermancinelli Differential Revision: https://reviews.llvm.org/D108390
2021-08-20 10:25:11 +00:00
// If a pre-defined output stream exists, dump the preprocessed content there
if (!ci.isOutputStreamNull()) {
// Send the output to the pre-defined output buffer.
ci.writeOutputStream(outForPP.str());
return;
}
// Create a file and save the preprocessed output there
std::unique_ptr<llvm::raw_pwrite_stream> os{ci.createDefaultOutputFile(
/*Binary=*/true, /*InFile=*/getCurrentFileOrBufferName())};
[flang] Refine output file generation This patch cleans-up the file generation code in Flang's frontend driver. It improves the layering between `CompilerInstance::CreateDefaultOutputFile`, `CompilerInstance::CreateOutputFile` and their various clients. * Rename `CreateOutputFile` as `CreateOutputFileImpl` and make it private. This method is an implementation detail. * Instead of passing an `std::error_code` out parameter into `CreateOutputFileImpl`, have it return Expected<>. This is a bit shorter and idiomatic LLVM. * Make `CreateDefaultOutputFile` (which calls `CreateOutputFileImpl`) issue an error when file creation fails. The error code from `CreateOutputFileImpl` is used to generate a meaningful diagnostic message. * Remove error reporting from `PrintPreprocessedAction::ExecuteAction`. This is only for cases when output file generation fails. This is handled in `CreateDefaultOutputFile` instead (see the previous point). * Inline `AddOutputFile` into its only caller, `CreateDefaultOutputFile`. * Switch from `lvm::buffer_ostream` to `llvm::buffer_unique_ostream>` for non-seekable output streams. This simplifies the logic in the driver and was introduced for this very reason in [1] * Moke sure that the diagnostics from the prescanner when running `-E` (`PrintPreprocessedAction::ExecuteAction`) are printed before the actual output is generated. * Update comments, add test. NOTE: This patch relands [2]. As suggested by Michael Kruse in the post-commit/post-revert review, I've added the following: ``` config.errc_messages = "@LLVM_LIT_ERRC_MESSAGES@" ``` in Flang's `lit.site.cfg.py.in`. This way, `%errc_ENOENT` in output-paths.f90 gets the correct value on Windows as well as on Linux. [1] https://reviews.llvm.org/D93260 [2] fd21d1e198e381a2b9e7af1701044462b2d386cd Reviewed By: ashermancinelli Differential Revision: https://reviews.llvm.org/D108390
2021-08-20 10:25:11 +00:00
if (!os) {
return;
}
[flang] Refine output file generation This patch cleans-up the file generation code in Flang's frontend driver. It improves the layering between `CompilerInstance::CreateDefaultOutputFile`, `CompilerInstance::CreateOutputFile` and their various clients. * Rename `CreateOutputFile` as `CreateOutputFileImpl` and make it private. This method is an implementation detail. * Instead of passing an `std::error_code` out parameter into `CreateOutputFileImpl`, have it return Expected<>. This is a bit shorter and idiomatic LLVM. * Make `CreateDefaultOutputFile` (which calls `CreateOutputFileImpl`) issue an error when file creation fails. The error code from `CreateOutputFileImpl` is used to generate a meaningful diagnostic message. * Remove error reporting from `PrintPreprocessedAction::ExecuteAction`. This is only for cases when output file generation fails. This is handled in `CreateDefaultOutputFile` instead (see the previous point). * Inline `AddOutputFile` into its only caller, `CreateDefaultOutputFile`. * Switch from `lvm::buffer_ostream` to `llvm::buffer_unique_ostream>` for non-seekable output streams. This simplifies the logic in the driver and was introduced for this very reason in [1] * Moke sure that the diagnostics from the prescanner when running `-E` (`PrintPreprocessedAction::ExecuteAction`) are printed before the actual output is generated. * Update comments, add test. NOTE: This patch relands [2]. As suggested by Michael Kruse in the post-commit/post-revert review, I've added the following: ``` config.errc_messages = "@LLVM_LIT_ERRC_MESSAGES@" ``` in Flang's `lit.site.cfg.py.in`. This way, `%errc_ENOENT` in output-paths.f90 gets the correct value on Windows as well as on Linux. [1] https://reviews.llvm.org/D93260 [2] fd21d1e198e381a2b9e7af1701044462b2d386cd Reviewed By: ashermancinelli Differential Revision: https://reviews.llvm.org/D108390
2021-08-20 10:25:11 +00:00
(*os) << outForPP.str();
}
void DebugDumpProvenanceAction::executeAction() {
this->getInstance().getParsing().DumpProvenance(llvm::outs());
}
void ParseSyntaxOnlyAction::executeAction() {}
void DebugUnparseNoSemaAction::executeAction() {
auto &invoc = this->getInstance().getInvocation();
auto &parseTree{getInstance().getParsing().parseTree()};
[flang][driver] Add debug options not requiring semantic checks This patch adds two debugging options in the new Flang driver (flang-new): *fdebug-unparse-no-sema *fdebug-dump-parse-tree-no-sema Each of these options combines two options from the "throwaway" driver (left: f18, right: flang-new): * `-fdebug-uparse -fdebug-no-semantics` --> `-fdebug-unparse-no-sema` * `-fdebug-dump-parse-tree -fdebug-no-semantics` --> `-fdebug-dump-parse-tree-no-sema` There are no plans to implement `-fdebug-no-semantics` in the new driver. Such option would be too powerful. Also, it would only make sense when combined with specific frontend actions (`-fdebug-unparse` and `-fdebug-dump-parse-tree`). Instead, this patch adds 2 specialised options listed above. Each of these is implemented through a dedicated FrontendAction (also added). The new frontend actions are implemented in terms of a new abstract base action: `PrescanAndSemaAction`. This new base class was required so that we can have finer control over what steps within the frontend are executed: * `PrescanAction`: run the _prescanner_ * `PrescanAndSemaAction`: run the _prescanner_ and the _parser_ (new in this patch) * `PrescanAndSemaAction`: run the _prescanner_, _parser_ and run the _semantic checks_ This patch introduces `PrescanAndParseAction::BeginSourceFileAction`. Apart from the semantic checks removed at the end, it is similar to `PrescanAndSemaAction::BeginSourceFileAction`. Differential Revision: https://reviews.llvm.org/D99645
2021-03-30 10:35:42 +00:00
// TODO: Options should come from CompilerInvocation
Unparse(llvm::outs(), *parseTree,
/*encoding=*/Fortran::parser::Encoding::UTF_8,
/*capitalizeKeywords=*/true, /*backslashEscapes=*/false,
/*preStatement=*/nullptr,
invoc.getUseAnalyzedObjectsForUnparse() ? &invoc.getAsFortran()
: nullptr);
[flang][driver] Add debug options not requiring semantic checks This patch adds two debugging options in the new Flang driver (flang-new): *fdebug-unparse-no-sema *fdebug-dump-parse-tree-no-sema Each of these options combines two options from the "throwaway" driver (left: f18, right: flang-new): * `-fdebug-uparse -fdebug-no-semantics` --> `-fdebug-unparse-no-sema` * `-fdebug-dump-parse-tree -fdebug-no-semantics` --> `-fdebug-dump-parse-tree-no-sema` There are no plans to implement `-fdebug-no-semantics` in the new driver. Such option would be too powerful. Also, it would only make sense when combined with specific frontend actions (`-fdebug-unparse` and `-fdebug-dump-parse-tree`). Instead, this patch adds 2 specialised options listed above. Each of these is implemented through a dedicated FrontendAction (also added). The new frontend actions are implemented in terms of a new abstract base action: `PrescanAndSemaAction`. This new base class was required so that we can have finer control over what steps within the frontend are executed: * `PrescanAction`: run the _prescanner_ * `PrescanAndSemaAction`: run the _prescanner_ and the _parser_ (new in this patch) * `PrescanAndSemaAction`: run the _prescanner_, _parser_ and run the _semantic checks_ This patch introduces `PrescanAndParseAction::BeginSourceFileAction`. Apart from the semantic checks removed at the end, it is similar to `PrescanAndSemaAction::BeginSourceFileAction`. Differential Revision: https://reviews.llvm.org/D99645
2021-03-30 10:35:42 +00:00
}
void DebugUnparseAction::executeAction() {
auto &invoc = this->getInstance().getInvocation();
auto &parseTree{getInstance().getParsing().parseTree()};
CompilerInstance &ci = this->getInstance();
auto os{ci.createDefaultOutputFile(
/*Binary=*/false, /*InFile=*/getCurrentFileOrBufferName())};
// TODO: Options should come from CompilerInvocation
Unparse(*os, *parseTree,
/*encoding=*/Fortran::parser::Encoding::UTF_8,
/*capitalizeKeywords=*/true, /*backslashEscapes=*/false,
/*preStatement=*/nullptr,
invoc.getUseAnalyzedObjectsForUnparse() ? &invoc.getAsFortran()
: nullptr);
// Report fatal semantic errors
reportFatalSemanticErrors();
}
void DebugUnparseWithSymbolsAction::executeAction() {
auto &parseTree{*getInstance().getParsing().parseTree()};
Fortran::semantics::UnparseWithSymbols(
llvm::outs(), parseTree, /*encoding=*/Fortran::parser::Encoding::UTF_8);
// Report fatal semantic errors
reportFatalSemanticErrors();
}
void DebugDumpSymbolsAction::executeAction() {
CompilerInstance &ci = this->getInstance();
if (!ci.getRtTyTables().schemata) {
unsigned diagID = ci.getDiagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error,
"could not find module file for __fortran_type_info");
ci.getDiagnostics().Report(diagID);
llvm::errs() << "\n";
return;
}
// Dump symbols
ci.getSemantics().DumpSymbols(llvm::outs());
}
void DebugDumpAllAction::executeAction() {
CompilerInstance &ci = this->getInstance();
// Dump parse tree
auto &parseTree{getInstance().getParsing().parseTree()};
llvm::outs() << "========================";
llvm::outs() << " Flang: parse tree dump ";
llvm::outs() << "========================\n";
Fortran::parser::DumpTree(llvm::outs(), parseTree,
&ci.getInvocation().getAsFortran());
if (!ci.getRtTyTables().schemata) {
unsigned diagID = ci.getDiagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error,
"could not find module file for __fortran_type_info");
ci.getDiagnostics().Report(diagID);
llvm::errs() << "\n";
return;
}
// Dump symbols
llvm::outs() << "=====================";
llvm::outs() << " Flang: symbols dump ";
llvm::outs() << "=====================\n";
ci.getSemantics().DumpSymbols(llvm::outs());
}
void DebugDumpParseTreeNoSemaAction::executeAction() {
auto &parseTree{getInstance().getParsing().parseTree()};
[flang][driver] Add debug options not requiring semantic checks This patch adds two debugging options in the new Flang driver (flang-new): *fdebug-unparse-no-sema *fdebug-dump-parse-tree-no-sema Each of these options combines two options from the "throwaway" driver (left: f18, right: flang-new): * `-fdebug-uparse -fdebug-no-semantics` --> `-fdebug-unparse-no-sema` * `-fdebug-dump-parse-tree -fdebug-no-semantics` --> `-fdebug-dump-parse-tree-no-sema` There are no plans to implement `-fdebug-no-semantics` in the new driver. Such option would be too powerful. Also, it would only make sense when combined with specific frontend actions (`-fdebug-unparse` and `-fdebug-dump-parse-tree`). Instead, this patch adds 2 specialised options listed above. Each of these is implemented through a dedicated FrontendAction (also added). The new frontend actions are implemented in terms of a new abstract base action: `PrescanAndSemaAction`. This new base class was required so that we can have finer control over what steps within the frontend are executed: * `PrescanAction`: run the _prescanner_ * `PrescanAndSemaAction`: run the _prescanner_ and the _parser_ (new in this patch) * `PrescanAndSemaAction`: run the _prescanner_, _parser_ and run the _semantic checks_ This patch introduces `PrescanAndParseAction::BeginSourceFileAction`. Apart from the semantic checks removed at the end, it is similar to `PrescanAndSemaAction::BeginSourceFileAction`. Differential Revision: https://reviews.llvm.org/D99645
2021-03-30 10:35:42 +00:00
// Dump parse tree
Fortran::parser::DumpTree(
llvm::outs(), parseTree,
&this->getInstance().getInvocation().getAsFortran());
[flang][driver] Add debug options not requiring semantic checks This patch adds two debugging options in the new Flang driver (flang-new): *fdebug-unparse-no-sema *fdebug-dump-parse-tree-no-sema Each of these options combines two options from the "throwaway" driver (left: f18, right: flang-new): * `-fdebug-uparse -fdebug-no-semantics` --> `-fdebug-unparse-no-sema` * `-fdebug-dump-parse-tree -fdebug-no-semantics` --> `-fdebug-dump-parse-tree-no-sema` There are no plans to implement `-fdebug-no-semantics` in the new driver. Such option would be too powerful. Also, it would only make sense when combined with specific frontend actions (`-fdebug-unparse` and `-fdebug-dump-parse-tree`). Instead, this patch adds 2 specialised options listed above. Each of these is implemented through a dedicated FrontendAction (also added). The new frontend actions are implemented in terms of a new abstract base action: `PrescanAndSemaAction`. This new base class was required so that we can have finer control over what steps within the frontend are executed: * `PrescanAction`: run the _prescanner_ * `PrescanAndSemaAction`: run the _prescanner_ and the _parser_ (new in this patch) * `PrescanAndSemaAction`: run the _prescanner_, _parser_ and run the _semantic checks_ This patch introduces `PrescanAndParseAction::BeginSourceFileAction`. Apart from the semantic checks removed at the end, it is similar to `PrescanAndSemaAction::BeginSourceFileAction`. Differential Revision: https://reviews.llvm.org/D99645
2021-03-30 10:35:42 +00:00
}
void DebugDumpParseTreeAction::executeAction() {
auto &parseTree{getInstance().getParsing().parseTree()};
// Dump parse tree
Fortran::parser::DumpTree(
llvm::outs(), parseTree,
&this->getInstance().getInvocation().getAsFortran());
// Report fatal semantic errors
reportFatalSemanticErrors();
}
[flang][driver] Add support for `-c` and `-emit-obj` This patch adds a frontend action for emitting object files. While Flang does not support code-generation, this action remains a placeholder. This patch simply provides glue-code to connect the compiler driver with the appropriate frontend action. The new action is triggered with the `-c` compiler driver flag, i.e. `flang-new -c`. This is then translated to `flang-new -fc1 -emit-obj`, so `-emit-obj` has to be marked as supported as well. As code-generation is not available yet, `flang-new -c` results in a driver error: ``` error: code-generation is not available yet ``` Hopefully this will help communicating the level of available functionality within Flang. The definition of `emit-obj` is updated so that it can be shared between Clang and Flang. As the original definition was enclosed within a Clang-specific TableGen `let` statement, it is extracted into a new `let` statement. That felt like the cleanest option. I also commented out `-triple` in Flang::ConstructJob and updated some comments there. This is similar to https://reviews.llvm.org/D93027. I wanted to make sure that it's clear that we can't support `-triple` until we have code-generation. However, once code-generation is available we _will need_ `-triple`. As this patch adds `-emit-obj`, the emit-obj.f90 becomes irrelevant and is deleted. Instead, phases.f90 is added to demonstrate that users can control compilation phases (indeed, `-c` is a phase control flag). Reviewed By: SouraVX, clementval Differential Revision: https://reviews.llvm.org/D93301
2021-01-07 09:08:54 +00:00
void DebugMeasureParseTreeAction::executeAction() {
CompilerInstance &ci = this->getInstance();
// Parse. In case of failure, report and return.
ci.getParsing().Parse(llvm::outs());
if (!ci.getParsing().messages().empty() &&
(ci.getInvocation().getWarnAsErr() ||
ci.getParsing().messages().AnyFatalError())) {
unsigned diagID = ci.getDiagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "Could not parse %0");
ci.getDiagnostics().Report(diagID) << getCurrentFileOrBufferName();
ci.getParsing().messages().Emit(llvm::errs(),
this->getInstance().getAllCookedSources());
return;
}
// Report the getDiagnostics from parsing
ci.getParsing().messages().Emit(llvm::errs(), ci.getAllCookedSources());
auto &parseTree{*ci.getParsing().parseTree()};
// Measure the parse tree
MeasurementVisitor visitor;
Fortran::parser::Walk(parseTree, visitor);
llvm::outs() << "Parse tree comprises " << visitor.objects
<< " objects and occupies " << visitor.bytes
<< " total bytes.\n";
}
void DebugPreFIRTreeAction::executeAction() {
CompilerInstance &ci = this->getInstance();
// Report and exit if fatal semantic errors are present
if (reportFatalSemanticErrors()) {
return;
}
auto &parseTree{*ci.getParsing().parseTree()};
// Dump pre-FIR tree
if (auto ast{Fortran::lower::createPFT(
parseTree, ci.getInvocation().getSemanticsContext())}) {
Fortran::lower::dumpPFT(llvm::outs(), *ast);
} else {
unsigned diagID = ci.getDiagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "Pre FIR Tree is NULL.");
ci.getDiagnostics().Report(diagID);
}
}
void DebugDumpParsingLogAction::executeAction() {
CompilerInstance &ci = this->getInstance();
ci.getParsing().Parse(llvm::errs());
ci.getParsing().DumpParsingLog(llvm::outs());
}
void GetDefinitionAction::executeAction() {
CompilerInstance &ci = this->getInstance();
// Report and exit if fatal semantic errors are present
if (reportFatalSemanticErrors()) {
return;
}
parser::AllCookedSources &cs = ci.getAllCookedSources();
unsigned diagID = ci.getDiagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "Symbol not found");
auto gdv = ci.getInvocation().getFrontendOpts().getDefVals;
auto charBlock{cs.GetCharBlockFromLineAndColumns(
gdv.line, gdv.startColumn, gdv.endColumn)};
if (!charBlock) {
ci.getDiagnostics().Report(diagID);
return;
}
llvm::outs() << "String range: >" << charBlock->ToString() << "<\n";
auto *symbol{ci.getInvocation()
.getSemanticsContext()
.FindScope(*charBlock)
.FindSymbol(*charBlock)};
if (!symbol) {
ci.getDiagnostics().Report(diagID);
return;
}
llvm::outs() << "Found symbol name: " << symbol->name().ToString() << "\n";
auto sourceInfo{cs.GetSourcePositionRange(symbol->name())};
if (!sourceInfo) {
llvm_unreachable(
"Failed to obtain SourcePosition."
"TODO: Please, write a test and replace this with a diagnostic!");
return;
}
llvm::outs() << "Found symbol name: " << symbol->name().ToString() << "\n";
llvm::outs() << symbol->name().ToString() << ": "
<< sourceInfo->first.file.path() << ", "
<< sourceInfo->first.line << ", " << sourceInfo->first.column
<< "-" << sourceInfo->second.column << "\n";
}
void GetSymbolsSourcesAction::executeAction() {
CompilerInstance &ci = this->getInstance();
// Report and exit if fatal semantic errors are present
if (reportFatalSemanticErrors()) {
return;
}
ci.getSemantics().DumpSymbolsSources(llvm::outs());
}
//===----------------------------------------------------------------------===//
// CodeGenActions
//===----------------------------------------------------------------------===//
CodeGenAction::~CodeGenAction() = default;
#include "flang/Tools/CLOptions.inc"
// Lower the previously generated MLIR module into an LLVM IR module
void CodeGenAction::generateLLVMIR() {
assert(mlirModule && "The MLIR module has not been generated yet.");
CompilerInstance &ci = this->getInstance();
fir::support::loadDialects(*mlirCtx);
fir::support::registerLLVMTranslation(*mlirCtx);
// Set-up the MLIR pass manager
mlir::PassManager pm(mlirCtx.get(), mlir::OpPassManager::Nesting::Implicit);
pm.addPass(std::make_unique<Fortran::lower::VerifierPass>());
pm.enableVerifier(/*verifyPasses=*/true);
// Create the pass pipeline
fir::createMLIRToLLVMPassPipeline(pm);
mlir::applyPassManagerCLOptions(pm);
// run the pass manager
if (!mlir::succeeded(pm.run(*mlirModule))) {
unsigned diagID = ci.getDiagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "Lowering to LLVM IR failed");
ci.getDiagnostics().Report(diagID);
}
// Translate to LLVM IR
llvm::Optional<llvm::StringRef> moduleName = mlirModule->getName();
llvmModule = mlir::translateModuleToLLVMIR(
*mlirModule, *llvmCtx, moduleName ? *moduleName : "FIRModule");
if (!llvmModule) {
unsigned diagID = ci.getDiagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "failed to create the LLVM module");
ci.getDiagnostics().Report(diagID);
return;
}
}
static llvm::CodeGenOpt::Level
getCGOptLevel(const Fortran::frontend::CodeGenOptions &opts) {
switch (opts.OptimizationLevel) {
default:
llvm_unreachable("Invalid optimization level!");
case 0:
return llvm::CodeGenOpt::None;
case 1:
return llvm::CodeGenOpt::Less;
case 2:
return llvm::CodeGenOpt::Default;
case 3:
return llvm::CodeGenOpt::Aggressive;
}
}
void CodeGenAction::setUpTargetMachine() {
CompilerInstance &ci = this->getInstance();
[flang][driver] Define the default frontend driver triple *SUMMARY* Currently, the frontend driver assumes that a target triple is either: * provided by the frontend itself (e.g. when lowering and generating code), * specified through the `-triple/-target` command line flags. If `-triple/-target` is not used, the frontend will simply use the host triple. This is going to be insufficient when e.g. consuming an LLVM IR file that has no triple specified (reading LLVM files is WIP, see D124667). We shouldn't require the triple to be specified via the command line in such situation. Instead, the frontend driver should contain a good default, e.g. the host triple. This patch updates Flang's `CompilerInvocation` to do just that, i.e. defines its default target triple. Similarly to Clang: * the default `CompilerInvocation` triple is set as the host triple, * the value specified with `-triple` takes precedence over the frontend driver default and the current module triple, * the frontend driver default takes precedence over the module triple. *TESTS* This change requires 2 unit tests to be updated. That's because relevant frontend actions are updated to assume that there's always a valid triple available in the current `CompilerInvocation`. This update is required because the unit tests bypass the regular `CompilerInvocation` set-up (in particular, they don't call `CompilerInvocation::CreateFromArgs`). I've also taken the liberty to disable the pre-precossor formatting in the affected unit tests as well (it is not required). No new tests are added. As `flang-new -fc1` does not support consuming LLVM IR files just yet, it is not possible to compile an LLVM IR file without a triple. More specifically, atm all LLVM IR files are generated and stored internally and the driver makes sure that these contain a valid target triple. This is about to change in D124667 (which adds support for reading LLVM IR/BC files) and that's where tests for exercising the default frontend driver triple will be added. *WHAT DOES CLANG DO?* For reference, the default target triple for Clang's `CompilerInvocation` is set through option marshalling infra [1] in Options.td. Please check the definition of the `-triple` flag: ``` def triple : Separate<["-"], "triple">, HelpText<"Specify target triple (e.g. i686-apple-darwin9)">, MarshallingInfoString<TargetOpts<"Triple">, "llvm::Triple::normalize(llvm::sys::getDefaultTargetTriple())">, AlwaysEmit, Normalizer<"normalizeTriple">; ``` Ideally, we should re-use the marshalling infra in Flang. [1] https://clang.llvm.org/docs/InternalsManual.html#option-marshalling-infrastructure Differential Revision: https://reviews.llvm.org/D124664
2022-04-28 14:12:32 +00:00
// Set the triple based on the CompilerInvocation set-up
const std::string &theTriple = ci.getInvocation().getTargetOpts().triple;
[flang][driver] Define the default frontend driver triple *SUMMARY* Currently, the frontend driver assumes that a target triple is either: * provided by the frontend itself (e.g. when lowering and generating code), * specified through the `-triple/-target` command line flags. If `-triple/-target` is not used, the frontend will simply use the host triple. This is going to be insufficient when e.g. consuming an LLVM IR file that has no triple specified (reading LLVM files is WIP, see D124667). We shouldn't require the triple to be specified via the command line in such situation. Instead, the frontend driver should contain a good default, e.g. the host triple. This patch updates Flang's `CompilerInvocation` to do just that, i.e. defines its default target triple. Similarly to Clang: * the default `CompilerInvocation` triple is set as the host triple, * the value specified with `-triple` takes precedence over the frontend driver default and the current module triple, * the frontend driver default takes precedence over the module triple. *TESTS* This change requires 2 unit tests to be updated. That's because relevant frontend actions are updated to assume that there's always a valid triple available in the current `CompilerInvocation`. This update is required because the unit tests bypass the regular `CompilerInvocation` set-up (in particular, they don't call `CompilerInvocation::CreateFromArgs`). I've also taken the liberty to disable the pre-precossor formatting in the affected unit tests as well (it is not required). No new tests are added. As `flang-new -fc1` does not support consuming LLVM IR files just yet, it is not possible to compile an LLVM IR file without a triple. More specifically, atm all LLVM IR files are generated and stored internally and the driver makes sure that these contain a valid target triple. This is about to change in D124667 (which adds support for reading LLVM IR/BC files) and that's where tests for exercising the default frontend driver triple will be added. *WHAT DOES CLANG DO?* For reference, the default target triple for Clang's `CompilerInvocation` is set through option marshalling infra [1] in Options.td. Please check the definition of the `-triple` flag: ``` def triple : Separate<["-"], "triple">, HelpText<"Specify target triple (e.g. i686-apple-darwin9)">, MarshallingInfoString<TargetOpts<"Triple">, "llvm::Triple::normalize(llvm::sys::getDefaultTargetTriple())">, AlwaysEmit, Normalizer<"normalizeTriple">; ``` Ideally, we should re-use the marshalling infra in Flang. [1] https://clang.llvm.org/docs/InternalsManual.html#option-marshalling-infrastructure Differential Revision: https://reviews.llvm.org/D124664
2022-04-28 14:12:32 +00:00
if (llvmModule->getTargetTriple() != theTriple) {
ci.getDiagnostics().Report(clang::diag::warn_fe_override_module)
<< theTriple;
[flang][driver] Define the default frontend driver triple *SUMMARY* Currently, the frontend driver assumes that a target triple is either: * provided by the frontend itself (e.g. when lowering and generating code), * specified through the `-triple/-target` command line flags. If `-triple/-target` is not used, the frontend will simply use the host triple. This is going to be insufficient when e.g. consuming an LLVM IR file that has no triple specified (reading LLVM files is WIP, see D124667). We shouldn't require the triple to be specified via the command line in such situation. Instead, the frontend driver should contain a good default, e.g. the host triple. This patch updates Flang's `CompilerInvocation` to do just that, i.e. defines its default target triple. Similarly to Clang: * the default `CompilerInvocation` triple is set as the host triple, * the value specified with `-triple` takes precedence over the frontend driver default and the current module triple, * the frontend driver default takes precedence over the module triple. *TESTS* This change requires 2 unit tests to be updated. That's because relevant frontend actions are updated to assume that there's always a valid triple available in the current `CompilerInvocation`. This update is required because the unit tests bypass the regular `CompilerInvocation` set-up (in particular, they don't call `CompilerInvocation::CreateFromArgs`). I've also taken the liberty to disable the pre-precossor formatting in the affected unit tests as well (it is not required). No new tests are added. As `flang-new -fc1` does not support consuming LLVM IR files just yet, it is not possible to compile an LLVM IR file without a triple. More specifically, atm all LLVM IR files are generated and stored internally and the driver makes sure that these contain a valid target triple. This is about to change in D124667 (which adds support for reading LLVM IR/BC files) and that's where tests for exercising the default frontend driver triple will be added. *WHAT DOES CLANG DO?* For reference, the default target triple for Clang's `CompilerInvocation` is set through option marshalling infra [1] in Options.td. Please check the definition of the `-triple` flag: ``` def triple : Separate<["-"], "triple">, HelpText<"Specify target triple (e.g. i686-apple-darwin9)">, MarshallingInfoString<TargetOpts<"Triple">, "llvm::Triple::normalize(llvm::sys::getDefaultTargetTriple())">, AlwaysEmit, Normalizer<"normalizeTriple">; ``` Ideally, we should re-use the marshalling infra in Flang. [1] https://clang.llvm.org/docs/InternalsManual.html#option-marshalling-infrastructure Differential Revision: https://reviews.llvm.org/D124664
2022-04-28 14:12:32 +00:00
llvmModule->setTargetTriple(theTriple);
}
// Create `Target`
std::string error;
const llvm::Target *theTarget =
llvm::TargetRegistry::lookupTarget(theTriple, error);
assert(theTarget && "Failed to create Target");
// Create `TargetMachine`
llvm::CodeGenOpt::Level OptLevel =
getCGOptLevel(ci.getInvocation().getCodeGenOpts());
tm.reset(theTarget->createTargetMachine(
theTriple, /*CPU=*/"",
/*Features=*/"", llvm::TargetOptions(), /*Reloc::Model=*/llvm::None,
/*CodeModel::Model=*/llvm::None, OptLevel));
assert(tm && "Failed to create TargetMachine");
}
static std::unique_ptr<llvm::raw_pwrite_stream>
getOutputStream(CompilerInstance &ci, llvm::StringRef inFile,
BackendActionTy action) {
switch (action) {
case BackendActionTy::Backend_EmitAssembly:
return ci.createDefaultOutputFile(
/*Binary=*/false, inFile, /*extension=*/"s");
case BackendActionTy::Backend_EmitLL:
return ci.createDefaultOutputFile(
/*Binary=*/false, inFile, /*extension=*/"ll");
case BackendActionTy::Backend_EmitMLIR:
return ci.createDefaultOutputFile(
/*Binary=*/false, inFile, /*extension=*/"mlir");
case BackendActionTy::Backend_EmitBC:
return ci.createDefaultOutputFile(
/*Binary=*/true, inFile, /*extension=*/"bc");
case BackendActionTy::Backend_EmitObj:
return ci.createDefaultOutputFile(
/*Binary=*/true, inFile, /*extension=*/"o");
}
llvm_unreachable("Invalid action!");
}
/// Generate target-specific machine-code or assembly file from the input LLVM
/// module.
///
/// \param [in] diags Diagnostics engine for reporting errors
/// \param [in] tm Target machine to aid the code-gen pipeline set-up
/// \param [in] act Backend act to run (assembly vs machine-code generation)
/// \param [in] llvmModule LLVM module to lower to assembly/machine-code
/// \param [out] os Output stream to emit the generated code to
static void generateMachineCodeOrAssemblyImpl(clang::DiagnosticsEngine &diags,
llvm::TargetMachine &tm,
BackendActionTy act,
llvm::Module &llvmModule,
llvm::raw_pwrite_stream &os) {
assert(((act == BackendActionTy::Backend_EmitObj) ||
(act == BackendActionTy::Backend_EmitAssembly)) &&
"Unsupported action");
// Set-up the pass manager, i.e create an LLVM code-gen pass pipeline.
// Currently only the legacy pass manager is supported.
// TODO: Switch to the new PM once it's available in the backend.
llvm::legacy::PassManager codeGenPasses;
codeGenPasses.add(
createTargetTransformInfoWrapperPass(tm.getTargetIRAnalysis()));
llvm::Triple triple(llvmModule.getTargetTriple());
std::unique_ptr<llvm::TargetLibraryInfoImpl> tlii =
std::make_unique<llvm::TargetLibraryInfoImpl>(triple);
assert(tlii && "Failed to create TargetLibraryInfo");
codeGenPasses.add(new llvm::TargetLibraryInfoWrapperPass(*tlii));
llvm::CodeGenFileType cgft = (act == BackendActionTy::Backend_EmitAssembly)
? llvm::CodeGenFileType::CGFT_AssemblyFile
: llvm::CodeGenFileType::CGFT_ObjectFile;
if (tm.addPassesToEmitFile(codeGenPasses, os, nullptr, cgft)) {
unsigned diagID =
diags.getCustomDiagID(clang::DiagnosticsEngine::Error,
"emission of this file type is not supported");
diags.Report(diagID);
return;
}
// Run the passes
codeGenPasses.run(llvmModule);
}
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
static llvm::OptimizationLevel
mapToLevel(const Fortran::frontend::CodeGenOptions &opts) {
switch (opts.OptimizationLevel) {
default:
llvm_unreachable("Invalid optimization level!");
case 0:
return llvm::OptimizationLevel::O0;
case 1:
return llvm::OptimizationLevel::O1;
case 2:
return llvm::OptimizationLevel::O2;
case 3:
return llvm::OptimizationLevel::O3;
}
}
void CodeGenAction::runOptimizationPipeline(llvm::raw_pwrite_stream &os) {
auto opts = getInstance().getInvocation().getCodeGenOpts();
llvm::OptimizationLevel level = mapToLevel(opts);
// Create the analysis managers.
llvm::LoopAnalysisManager lam;
llvm::FunctionAnalysisManager fam;
llvm::CGSCCAnalysisManager cgam;
llvm::ModuleAnalysisManager mam;
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
// Create the pass manager builder.
llvm::PassInstrumentationCallbacks pic;
llvm::PipelineTuningOptions pto;
llvm::Optional<llvm::PGOOptions> pgoOpt;
llvm::StandardInstrumentations si(opts.DebugPassManager);
si.registerCallbacks(pic, &fam);
llvm::PassBuilder pb(tm.get(), pto, pgoOpt, &pic);
// Register all the basic analyses with the managers.
pb.registerModuleAnalyses(mam);
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
pb.registerCGSCCAnalyses(cgam);
pb.registerFunctionAnalyses(fam);
pb.registerLoopAnalyses(lam);
pb.crossRegisterProxies(lam, fam, cgam, mam);
// Create the pass manager.
llvm::ModulePassManager mpm;
if (opts.OptimizationLevel == 0)
mpm = pb.buildO0DefaultPipeline(level, false);
else
mpm = pb.buildPerModuleDefaultPipeline(level);
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
if (action == BackendActionTy::Backend_EmitBC)
mpm.addPass(llvm::BitcodeWriterPass(os));
// Run the passes.
mpm.run(*llvmModule, mam);
}
[flang][driver] Add support for -S and implement -c/-emit-obj This patch adds support for: * `-S` in Flang's compiler and frontend drivers, and implements: * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler driver (this is consistent with Clang). (these options were already available before, but only as placeholders). The semantics of these options in Clang and Flang are identical. The `EmitObjAction` frontend action is renamed as `BackendAction`. This new name more accurately reflects the fact that this action will primarily run the code-gen/backend pipeline in LLVM. It also makes more sense as an action implementing both `-emit-obj` and `-S` (originally, it was just `-emit-obj`). `tripleName` from FirContext.cpp is deleted and, when a target triple is required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used instead. In practice, this means that `fir.triple` is replaced with `llvm.target_triple`. The former was effectively ignored. The latter is used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's embedded in the generated LLVM IR module). The driver can then re-use it when configuring the backend. With this change, the LLVM IR files generated by e.g. `tco` will from now on contain the correct target triple. The code-gen.f90 test is replaced with code-gen-x86.f90 and code-gen-aarch64.f90. With 2 seperate files we can verify that `--target` is correctly taken into account. LIT configuration is updated to enable e.g.: ``` ! REQUIRES: aarch64-registered-target ``` Differential Revision: https://reviews.llvm.org/D120568
2022-02-24 17:34:27 +00:00
void CodeGenAction::executeAction() {
CompilerInstance &ci = this->getInstance();
[flang][driver] Add support for -S and implement -c/-emit-obj This patch adds support for: * `-S` in Flang's compiler and frontend drivers, and implements: * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler driver (this is consistent with Clang). (these options were already available before, but only as placeholders). The semantics of these options in Clang and Flang are identical. The `EmitObjAction` frontend action is renamed as `BackendAction`. This new name more accurately reflects the fact that this action will primarily run the code-gen/backend pipeline in LLVM. It also makes more sense as an action implementing both `-emit-obj` and `-S` (originally, it was just `-emit-obj`). `tripleName` from FirContext.cpp is deleted and, when a target triple is required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used instead. In practice, this means that `fir.triple` is replaced with `llvm.target_triple`. The former was effectively ignored. The latter is used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's embedded in the generated LLVM IR module). The driver can then re-use it when configuring the backend. With this change, the LLVM IR files generated by e.g. `tco` will from now on contain the correct target triple. The code-gen.f90 test is replaced with code-gen-x86.f90 and code-gen-aarch64.f90. With 2 seperate files we can verify that `--target` is correctly taken into account. LIT configuration is updated to enable e.g.: ``` ! REQUIRES: aarch64-registered-target ``` Differential Revision: https://reviews.llvm.org/D120568
2022-02-24 17:34:27 +00:00
// If the output stream is a file, generate it and define the corresponding
// output stream. If a pre-defined output stream is available, we will use
// that instead.
//
// NOTE: `os` is a smart pointer that will be destroyed at the end of this
// method. However, it won't be written to until `codeGenPasses` is
// destroyed. By defining `os` before `codeGenPasses`, we make sure that the
[flang][driver] Add support for -S and implement -c/-emit-obj This patch adds support for: * `-S` in Flang's compiler and frontend drivers, and implements: * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler driver (this is consistent with Clang). (these options were already available before, but only as placeholders). The semantics of these options in Clang and Flang are identical. The `EmitObjAction` frontend action is renamed as `BackendAction`. This new name more accurately reflects the fact that this action will primarily run the code-gen/backend pipeline in LLVM. It also makes more sense as an action implementing both `-emit-obj` and `-S` (originally, it was just `-emit-obj`). `tripleName` from FirContext.cpp is deleted and, when a target triple is required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used instead. In practice, this means that `fir.triple` is replaced with `llvm.target_triple`. The former was effectively ignored. The latter is used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's embedded in the generated LLVM IR module). The driver can then re-use it when configuring the backend. With this change, the LLVM IR files generated by e.g. `tco` will from now on contain the correct target triple. The code-gen.f90 test is replaced with code-gen-x86.f90 and code-gen-aarch64.f90. With 2 seperate files we can verify that `--target` is correctly taken into account. LIT configuration is updated to enable e.g.: ``` ! REQUIRES: aarch64-registered-target ``` Differential Revision: https://reviews.llvm.org/D120568
2022-02-24 17:34:27 +00:00
// output stream won't be destroyed before it is written to. This only
// applies when an output file is used (i.e. there is no pre-defined output
// stream).
// TODO: Revisit once the new PM is ready (i.e. when `codeGenPasses` is
[flang][driver] Add support for -S and implement -c/-emit-obj This patch adds support for: * `-S` in Flang's compiler and frontend drivers, and implements: * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler driver (this is consistent with Clang). (these options were already available before, but only as placeholders). The semantics of these options in Clang and Flang are identical. The `EmitObjAction` frontend action is renamed as `BackendAction`. This new name more accurately reflects the fact that this action will primarily run the code-gen/backend pipeline in LLVM. It also makes more sense as an action implementing both `-emit-obj` and `-S` (originally, it was just `-emit-obj`). `tripleName` from FirContext.cpp is deleted and, when a target triple is required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used instead. In practice, this means that `fir.triple` is replaced with `llvm.target_triple`. The former was effectively ignored. The latter is used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's embedded in the generated LLVM IR module). The driver can then re-use it when configuring the backend. With this change, the LLVM IR files generated by e.g. `tco` will from now on contain the correct target triple. The code-gen.f90 test is replaced with code-gen-x86.f90 and code-gen-aarch64.f90. With 2 seperate files we can verify that `--target` is correctly taken into account. LIT configuration is updated to enable e.g.: ``` ! REQUIRES: aarch64-registered-target ``` Differential Revision: https://reviews.llvm.org/D120568
2022-02-24 17:34:27 +00:00
// updated to use it).
std::unique_ptr<llvm::raw_pwrite_stream> os;
if (ci.isOutputStreamNull()) {
os = getOutputStream(ci, getCurrentFileOrBufferName(), action);
[flang][driver] Add support for -S and implement -c/-emit-obj This patch adds support for: * `-S` in Flang's compiler and frontend drivers, and implements: * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler driver (this is consistent with Clang). (these options were already available before, but only as placeholders). The semantics of these options in Clang and Flang are identical. The `EmitObjAction` frontend action is renamed as `BackendAction`. This new name more accurately reflects the fact that this action will primarily run the code-gen/backend pipeline in LLVM. It also makes more sense as an action implementing both `-emit-obj` and `-S` (originally, it was just `-emit-obj`). `tripleName` from FirContext.cpp is deleted and, when a target triple is required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used instead. In practice, this means that `fir.triple` is replaced with `llvm.target_triple`. The former was effectively ignored. The latter is used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's embedded in the generated LLVM IR module). The driver can then re-use it when configuring the backend. With this change, the LLVM IR files generated by e.g. `tco` will from now on contain the correct target triple. The code-gen.f90 test is replaced with code-gen-x86.f90 and code-gen-aarch64.f90. With 2 seperate files we can verify that `--target` is correctly taken into account. LIT configuration is updated to enable e.g.: ``` ! REQUIRES: aarch64-registered-target ``` Differential Revision: https://reviews.llvm.org/D120568
2022-02-24 17:34:27 +00:00
if (!os) {
unsigned diagID = ci.getDiagnostics().getCustomDiagID(
[flang][driver] Add support for -S and implement -c/-emit-obj This patch adds support for: * `-S` in Flang's compiler and frontend drivers, and implements: * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler driver (this is consistent with Clang). (these options were already available before, but only as placeholders). The semantics of these options in Clang and Flang are identical. The `EmitObjAction` frontend action is renamed as `BackendAction`. This new name more accurately reflects the fact that this action will primarily run the code-gen/backend pipeline in LLVM. It also makes more sense as an action implementing both `-emit-obj` and `-S` (originally, it was just `-emit-obj`). `tripleName` from FirContext.cpp is deleted and, when a target triple is required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used instead. In practice, this means that `fir.triple` is replaced with `llvm.target_triple`. The former was effectively ignored. The latter is used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's embedded in the generated LLVM IR module). The driver can then re-use it when configuring the backend. With this change, the LLVM IR files generated by e.g. `tco` will from now on contain the correct target triple. The code-gen.f90 test is replaced with code-gen-x86.f90 and code-gen-aarch64.f90. With 2 seperate files we can verify that `--target` is correctly taken into account. LIT configuration is updated to enable e.g.: ``` ! REQUIRES: aarch64-registered-target ``` Differential Revision: https://reviews.llvm.org/D120568
2022-02-24 17:34:27 +00:00
clang::DiagnosticsEngine::Error, "failed to create the output file");
ci.getDiagnostics().Report(diagID);
[flang][driver] Add support for -S and implement -c/-emit-obj This patch adds support for: * `-S` in Flang's compiler and frontend drivers, and implements: * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler driver (this is consistent with Clang). (these options were already available before, but only as placeholders). The semantics of these options in Clang and Flang are identical. The `EmitObjAction` frontend action is renamed as `BackendAction`. This new name more accurately reflects the fact that this action will primarily run the code-gen/backend pipeline in LLVM. It also makes more sense as an action implementing both `-emit-obj` and `-S` (originally, it was just `-emit-obj`). `tripleName` from FirContext.cpp is deleted and, when a target triple is required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used instead. In practice, this means that `fir.triple` is replaced with `llvm.target_triple`. The former was effectively ignored. The latter is used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's embedded in the generated LLVM IR module). The driver can then re-use it when configuring the backend. With this change, the LLVM IR files generated by e.g. `tco` will from now on contain the correct target triple. The code-gen.f90 test is replaced with code-gen-x86.f90 and code-gen-aarch64.f90. With 2 seperate files we can verify that `--target` is correctly taken into account. LIT configuration is updated to enable e.g.: ``` ! REQUIRES: aarch64-registered-target ``` Differential Revision: https://reviews.llvm.org/D120568
2022-02-24 17:34:27 +00:00
return;
}
}
if (action == BackendActionTy::Backend_EmitMLIR) {
mlirModule->print(ci.isOutputStreamNull() ? *os : ci.getOutputStream());
return;
}
[flang][driver] Add support for -S and implement -c/-emit-obj This patch adds support for: * `-S` in Flang's compiler and frontend drivers, and implements: * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler driver (this is consistent with Clang). (these options were already available before, but only as placeholders). The semantics of these options in Clang and Flang are identical. The `EmitObjAction` frontend action is renamed as `BackendAction`. This new name more accurately reflects the fact that this action will primarily run the code-gen/backend pipeline in LLVM. It also makes more sense as an action implementing both `-emit-obj` and `-S` (originally, it was just `-emit-obj`). `tripleName` from FirContext.cpp is deleted and, when a target triple is required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used instead. In practice, this means that `fir.triple` is replaced with `llvm.target_triple`. The former was effectively ignored. The latter is used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's embedded in the generated LLVM IR module). The driver can then re-use it when configuring the backend. With this change, the LLVM IR files generated by e.g. `tco` will from now on contain the correct target triple. The code-gen.f90 test is replaced with code-gen-x86.f90 and code-gen-aarch64.f90. With 2 seperate files we can verify that `--target` is correctly taken into account. LIT configuration is updated to enable e.g.: ``` ! REQUIRES: aarch64-registered-target ``` Differential Revision: https://reviews.llvm.org/D120568
2022-02-24 17:34:27 +00:00
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
// 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();
[flang][driver] Add support for -S and implement -c/-emit-obj This patch adds support for: * `-S` in Flang's compiler and frontend drivers, and implements: * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler driver (this is consistent with Clang). (these options were already available before, but only as placeholders). The semantics of these options in Clang and Flang are identical. The `EmitObjAction` frontend action is renamed as `BackendAction`. This new name more accurately reflects the fact that this action will primarily run the code-gen/backend pipeline in LLVM. It also makes more sense as an action implementing both `-emit-obj` and `-S` (originally, it was just `-emit-obj`). `tripleName` from FirContext.cpp is deleted and, when a target triple is required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used instead. In practice, this means that `fir.triple` is replaced with `llvm.target_triple`. The former was effectively ignored. The latter is used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's embedded in the generated LLVM IR module). The driver can then re-use it when configuring the backend. With this change, the LLVM IR files generated by e.g. `tco` will from now on contain the correct target triple. The code-gen.f90 test is replaced with code-gen-x86.f90 and code-gen-aarch64.f90. With 2 seperate files we can verify that `--target` is correctly taken into account. LIT configuration is updated to enable e.g.: ``` ! REQUIRES: aarch64-registered-target ``` Differential Revision: https://reviews.llvm.org/D120568
2022-02-24 17:34:27 +00:00
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
// Run LLVM's middle-end (i.e. the optimizer).
runOptimizationPipeline(*os);
if (action == BackendActionTy::Backend_EmitLL) {
llvmModule->print(ci.isOutputStreamNull() ? *os : ci.getOutputStream(),
/*AssemblyAnnotationWriter=*/nullptr);
return;
}
setUpTargetMachine();
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
llvmModule->setDataLayout(tm->createDataLayout());
if (action == BackendActionTy::Backend_EmitBC) {
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
// This action has effectively been completed in runOptimizationPipeline.
[flang][driver] Add support for -S and implement -c/-emit-obj This patch adds support for: * `-S` in Flang's compiler and frontend drivers, and implements: * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler driver (this is consistent with Clang). (these options were already available before, but only as placeholders). The semantics of these options in Clang and Flang are identical. The `EmitObjAction` frontend action is renamed as `BackendAction`. This new name more accurately reflects the fact that this action will primarily run the code-gen/backend pipeline in LLVM. It also makes more sense as an action implementing both `-emit-obj` and `-S` (originally, it was just `-emit-obj`). `tripleName` from FirContext.cpp is deleted and, when a target triple is required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used instead. In practice, this means that `fir.triple` is replaced with `llvm.target_triple`. The former was effectively ignored. The latter is used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's embedded in the generated LLVM IR module). The driver can then re-use it when configuring the backend. With this change, the LLVM IR files generated by e.g. `tco` will from now on contain the correct target triple. The code-gen.f90 test is replaced with code-gen-x86.f90 and code-gen-aarch64.f90. With 2 seperate files we can verify that `--target` is correctly taken into account. LIT configuration is updated to enable e.g.: ``` ! REQUIRES: aarch64-registered-target ``` Differential Revision: https://reviews.llvm.org/D120568
2022-02-24 17:34:27 +00:00
return;
}
[flang][driver] Add support for `-O{0|1|2|3}` This patch adds support for most common optimisation compiler flags: `-O{0|1|2|3}`. This is implemented in both the compiler and frontend drivers. At this point, these options are only used to configure the LLVM optimisation pipelines (aka middle-end). LLVM backend or MLIR/FIR optimisations are not supported yet. Previously, the middle-end pass manager was only required when generating LLVM bitcode (i.e. for `flang-new -c -emit-llvm <file>` or `flang-new -fc1 -emit-llvm-bc <file>`). With this change, it becomes required for all frontend actions that are represented as `CodeGenAction` and `CodeGenAction::executeAction` is refactored accordingly (in the spirit of better code re-use). Additionally, the `-fdebug-pass-manager` option is enabled to facilitate testing. This flag can be used to configure the pass manager to print the middle-end passes that are being run. Similar option exists in Clang and the semantics in Flang are identical. This option translates to extra configuration when setting up the pass manager. This is implemented in `CodeGenAction::runOptimizationPipeline`. This patch also adds some bolier plate code to manage code-gen options ("code-gen" refers to generating machine code in LLVM in this context). This was extracted from Clang. In Clang, it simplifies defining code-gen options and enables option marshalling. In Flang, option marshalling is not yet supported (we might do at some point), but being able to auto-generate some code with macros is beneficial. This will become particularly apparent when we start adding more options (at least in Clang, the list of code-gen options is rather long). Differential Revision: https://reviews.llvm.org/D128043
2022-06-06 09:44:21 +00:00
// Run LLVM's backend and generate either assembly or machine code
if (action == BackendActionTy::Backend_EmitAssembly ||
action == BackendActionTy::Backend_EmitObj) {
generateMachineCodeOrAssemblyImpl(
ci.getDiagnostics(), *tm, action, *llvmModule,
ci.isOutputStreamNull() ? *os : ci.getOutputStream());
return;
}
[flang][driver] Add support for `-c` and `-emit-obj` This patch adds a frontend action for emitting object files. While Flang does not support code-generation, this action remains a placeholder. This patch simply provides glue-code to connect the compiler driver with the appropriate frontend action. The new action is triggered with the `-c` compiler driver flag, i.e. `flang-new -c`. This is then translated to `flang-new -fc1 -emit-obj`, so `-emit-obj` has to be marked as supported as well. As code-generation is not available yet, `flang-new -c` results in a driver error: ``` error: code-generation is not available yet ``` Hopefully this will help communicating the level of available functionality within Flang. The definition of `emit-obj` is updated so that it can be shared between Clang and Flang. As the original definition was enclosed within a Clang-specific TableGen `let` statement, it is extracted into a new `let` statement. That felt like the cleanest option. I also commented out `-triple` in Flang::ConstructJob and updated some comments there. This is similar to https://reviews.llvm.org/D93027. I wanted to make sure that it's clear that we can't support `-triple` until we have code-generation. However, once code-generation is available we _will need_ `-triple`. As this patch adds `-emit-obj`, the emit-obj.f90 becomes irrelevant and is deleted. Instead, phases.f90 is added to demonstrate that users can control compilation phases (indeed, `-c` is a phase control flag). Reviewed By: SouraVX, clementval Differential Revision: https://reviews.llvm.org/D93301
2021-01-07 09:08:54 +00:00
}
void InitOnlyAction::executeAction() {
CompilerInstance &ci = this->getInstance();
unsigned diagID = ci.getDiagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Warning,
"Use `-init-only` for testing purposes only");
ci.getDiagnostics().Report(diagID);
}
void PluginParseTreeAction::executeAction() {}
void DebugDumpPFTAction::executeAction() {
CompilerInstance &ci = this->getInstance();
if (auto ast = Fortran::lower::createPFT(*ci.getParsing().parseTree(),
ci.getSemantics().context())) {
Fortran::lower::dumpPFT(llvm::outs(), *ast);
return;
}
unsigned diagID = ci.getDiagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "Pre FIR Tree is NULL.");
ci.getDiagnostics().Report(diagID);
}
Fortran::parser::Parsing &PluginParseTreeAction::getParsing() {
return getInstance().getParsing();
}
std::unique_ptr<llvm::raw_pwrite_stream>
PluginParseTreeAction::createOutputFile(llvm::StringRef extension = "") {
std::unique_ptr<llvm::raw_pwrite_stream> os{
getInstance().createDefaultOutputFile(
/*Binary=*/false, /*InFile=*/getCurrentFileOrBufferName(),
extension)};
return os;
}