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

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

650 lines
22 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
//
//===----------------------------------------------------------------------===//
[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/Pass/PassManager.h"
#include "mlir/Target/LLVMIR/ModuleTranslation.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/MC/TargetRegistry.h"
#include "llvm/Passes/PassBuilder.h"
#include "llvm/Support/ErrorHandling.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 <clang/Basic/Diagnostic.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() {
bool res = RunPrescan() && RunParse() && RunSemanticChecks();
if (!res)
return res;
CompilerInstance &ci = this->instance();
// 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);
// Create a LoweringBridge
const common::IntrinsicTypeDefaultKinds &defKinds =
ci.invocation().semanticsContext().defaultKinds();
fir::KindMapping kindMap(mlirCtx.get(),
llvm::ArrayRef<fir::KindTy>{fir::fromDefaultKinds(defKinds)});
lower::LoweringBridge lb = Fortran::lower::LoweringBridge::create(*mlirCtx,
defKinds, ci.invocation().semanticsContext().intrinsics(),
ci.parsing().allCooked(), ci.invocation().targetOpts().triple, kindMap);
// Create a parse tree and lower it to FIR
Fortran::parser::Program &parseTree{*ci.parsing().parseTree()};
lb.lower(parseTree, ci.invocation().semanticsContext());
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.diagnostics().getCustomDiagID(clang::DiagnosticsEngine::Error,
"verification of lowering to FIR failed");
ci.diagnostics().Report(diagID);
return false;
}
return true;
}
//===----------------------------------------------------------------------===//
// Custom ExecuteAction
//===----------------------------------------------------------------------===//
void InputOutputTestAction::ExecuteAction() {
CompilerInstance &ci = instance();
// 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 error_stream{buf};
// Read the input file
Fortran::parser::AllSources &allSources{ci.allSources()};
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(error_stream);
else
sf = allSources.Open(path, error_stream, 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
[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
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->instance();
if (ci.invocation().preprocessorOpts().noReformat) {
ci.parsing().DumpCookedChars(outForPP);
} else {
ci.parsing().EmitPreprocessedSource(
outForPP, !ci.invocation().preprocessorOpts().noLineDirectives);
}
[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
// Print diagnostics from the prescanner
ci.parsing().messages().Emit(llvm::errs(), ci.allCookedSources());
// 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
[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
std::unique_ptr<llvm::raw_pwrite_stream> os{ci.CreateDefaultOutputFile(
/*Binary=*/true, /*InFile=*/GetCurrentFileOrBufferName())};
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->instance().parsing().DumpProvenance(llvm::outs());
}
void ParseSyntaxOnlyAction::ExecuteAction() {
}
[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 DebugUnparseNoSemaAction::ExecuteAction() {
auto &invoc = this->instance().invocation();
[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
auto &parseTree{instance().parsing().parseTree()};
// TODO: Options should come from CompilerInvocation
Unparse(llvm::outs(), *parseTree,
/*encoding=*/Fortran::parser::Encoding::UTF_8,
/*capitalizeKeywords=*/true, /*backslashEscapes=*/false,
/*preStatement=*/nullptr,
invoc.useAnalyzedObjectsForUnparse() ? &invoc.asFortran() : 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->instance().invocation();
auto &parseTree{instance().parsing().parseTree()};
CompilerInstance &ci = this->instance();
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.useAnalyzedObjectsForUnparse() ? &invoc.asFortran() : nullptr);
// Report fatal semantic errors
reportFatalSemanticErrors();
}
void DebugUnparseWithSymbolsAction::ExecuteAction() {
auto &parseTree{*instance().parsing().parseTree()};
Fortran::semantics::UnparseWithSymbols(
llvm::outs(), parseTree, /*encoding=*/Fortran::parser::Encoding::UTF_8);
// Report fatal semantic errors
reportFatalSemanticErrors();
}
void DebugDumpSymbolsAction::ExecuteAction() {
CompilerInstance &ci = this->instance();
if (!ci.getRtTyTables().schemata) {
unsigned DiagID =
ci.diagnostics().getCustomDiagID(clang::DiagnosticsEngine::Error,
"could not find module file for __fortran_type_info");
ci.diagnostics().Report(DiagID);
llvm::errs() << "\n";
return;
}
// Dump symbols
ci.semantics().DumpSymbols(llvm::outs());
}
void DebugDumpAllAction::ExecuteAction() {
CompilerInstance &ci = this->instance();
// Dump parse tree
auto &parseTree{instance().parsing().parseTree()};
llvm::outs() << "========================";
llvm::outs() << " Flang: parse tree dump ";
llvm::outs() << "========================\n";
Fortran::parser::DumpTree(
llvm::outs(), parseTree, &ci.invocation().asFortran());
if (!ci.getRtTyTables().schemata) {
unsigned DiagID =
ci.diagnostics().getCustomDiagID(clang::DiagnosticsEngine::Error,
"could not find module file for __fortran_type_info");
ci.diagnostics().Report(DiagID);
llvm::errs() << "\n";
return;
}
// Dump symbols
llvm::outs() << "=====================";
llvm::outs() << " Flang: symbols dump ";
llvm::outs() << "=====================\n";
ci.semantics().DumpSymbols(llvm::outs());
}
[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 DebugDumpParseTreeNoSemaAction::ExecuteAction() {
auto &parseTree{instance().parsing().parseTree()};
// Dump parse tree
Fortran::parser::DumpTree(
llvm::outs(), parseTree, &this->instance().invocation().asFortran());
[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{instance().parsing().parseTree()};
// Dump parse tree
Fortran::parser::DumpTree(
llvm::outs(), parseTree, &this->instance().invocation().asFortran());
// 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->instance();
// Parse. In case of failure, report and return.
ci.parsing().Parse(llvm::outs());
if (!ci.parsing().messages().empty() &&
(ci.invocation().warnAsErr() ||
ci.parsing().messages().AnyFatalError())) {
unsigned diagID = ci.diagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "Could not parse %0");
ci.diagnostics().Report(diagID) << GetCurrentFileOrBufferName();
ci.parsing().messages().Emit(
llvm::errs(), this->instance().allCookedSources());
return;
}
// Report the diagnostics from parsing
ci.parsing().messages().Emit(llvm::errs(), ci.allCookedSources());
auto &parseTree{*ci.parsing().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->instance();
// Report and exit if fatal semantic errors are present
if (reportFatalSemanticErrors()) {
return;
}
auto &parseTree{*ci.parsing().parseTree()};
// Dump pre-FIR tree
if (auto ast{Fortran::lower::createPFT(
parseTree, ci.invocation().semanticsContext())}) {
Fortran::lower::dumpPFT(llvm::outs(), *ast);
} else {
unsigned diagID = ci.diagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "Pre FIR Tree is NULL.");
ci.diagnostics().Report(diagID);
}
}
void DebugDumpParsingLogAction::ExecuteAction() {
CompilerInstance &ci = this->instance();
ci.parsing().Parse(llvm::errs());
ci.parsing().DumpParsingLog(llvm::outs());
}
void GetDefinitionAction::ExecuteAction() {
CompilerInstance &ci = this->instance();
// Report and exit if fatal semantic errors are present
if (reportFatalSemanticErrors()) {
return;
}
parser::AllCookedSources &cs = ci.allCookedSources();
unsigned diagID = ci.diagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "Symbol not found");
auto gdv = ci.invocation().frontendOpts().getDefVals;
auto charBlock{cs.GetCharBlockFromLineAndColumns(
gdv.line, gdv.startColumn, gdv.endColumn)};
if (!charBlock) {
ci.diagnostics().Report(diagID);
return;
}
llvm::outs() << "String range: >" << charBlock->ToString() << "<\n";
auto *symbol{ci.invocation()
.semanticsContext()
.FindScope(*charBlock)
.FindSymbol(*charBlock)};
if (!symbol) {
ci.diagnostics().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->instance();
// Report and exit if fatal semantic errors are present
if (reportFatalSemanticErrors()) {
return;
}
ci.semantics().DumpSymbolsSources(llvm::outs());
}
#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->instance();
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);
// Run the pass manager
if (!mlir::succeeded(pm.run(*mlirModule))) {
unsigned diagID = ci.diagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "Lowering to LLVM IR failed");
ci.diagnostics().Report(diagID);
}
// Translate to LLVM IR
llvm::Optional<llvm::StringRef> moduleName = mlirModule->getName();
llvmCtx = std::make_unique<llvm::LLVMContext>();
llvmModule = mlir::translateModuleToLLVMIR(
*mlirModule, *llvmCtx, moduleName ? *moduleName : "FIRModule");
if (!llvmModule) {
unsigned diagID = ci.diagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "failed to create the LLVM module");
ci.diagnostics().Report(diagID);
return;
}
}
void EmitLLVMAction::ExecuteAction() {
CompilerInstance &ci = this->instance();
GenerateLLVMIR();
// If set, use the predefined outupt stream to print the generated module.
if (!ci.IsOutputStreamNull()) {
llvmModule->print(
ci.GetOutputStream(), /*AssemblyAnnotationWriter=*/nullptr);
return;
}
// No predefined output stream was set. Create an output file and dump the
// generated module there.
std::unique_ptr<llvm::raw_ostream> os = ci.CreateDefaultOutputFile(
/*Binary=*/false, /*InFile=*/GetCurrentFileOrBufferName(), "ll");
if (!os) {
unsigned diagID = ci.diagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "failed to create the output file");
ci.diagnostics().Report(diagID);
return;
}
llvmModule->print(*os, /*AssemblyAnnotationWriter=*/nullptr);
}
void EmitLLVMBitcodeAction::ExecuteAction() {
CompilerInstance &ci = this->instance();
// Generate an LLVM module if it's not already present (it will already be
// present if the input file is an LLVM IR/BC file).
if (!llvmModule)
GenerateLLVMIR();
// Create and configure `Target`
std::string error;
std::string theTriple = llvmModule->getTargetTriple();
const llvm::Target *theTarget =
llvm::TargetRegistry::lookupTarget(theTriple, error);
assert(theTarget && "Failed to create Target");
// Create and configure `TargetMachine`
std::unique_ptr<llvm::TargetMachine> TM(
theTarget->createTargetMachine(theTriple, /*CPU=*/"",
/*Features=*/"", llvm::TargetOptions(), llvm::None));
assert(TM && "Failed to create TargetMachine");
llvmModule->setDataLayout(TM->createDataLayout());
// Generate an output file
std::unique_ptr<llvm::raw_ostream> os = ci.CreateDefaultOutputFile(
/*Binary=*/true, /*InFile=*/GetCurrentFileOrBufferName(), "bc");
if (!os) {
unsigned diagID = ci.diagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "failed to create the output file");
ci.diagnostics().Report(diagID);
return;
}
// Set-up the pass manager
llvm::ModulePassManager MPM;
llvm::ModuleAnalysisManager MAM;
llvm::PassBuilder PB(TM.get());
PB.registerModuleAnalyses(MAM);
MPM.addPass(llvm::BitcodeWriterPass(*os));
// Run the passes
MPM.run(*llvmModule, MAM);
}
void EmitMLIRAction::ExecuteAction() {
CompilerInstance &ci = this->instance();
// Print the output. If a pre-defined output stream exists, dump the MLIR
// content there.
if (!ci.IsOutputStreamNull()) {
mlirModule->print(ci.GetOutputStream());
return;
}
// ... otherwise, print to a file.
std::unique_ptr<llvm::raw_pwrite_stream> os{ci.CreateDefaultOutputFile(
/*Binary=*/true, /*InFile=*/GetCurrentFileOrBufferName(), "mlir")};
if (!os) {
unsigned diagID = ci.diagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "failed to create the output file");
ci.diagnostics().Report(diagID);
return;
}
mlirModule->print(*os);
}
[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 BackendAction::ExecuteAction() {
[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
CompilerInstance &ci = this->instance();
[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
// Generate an LLVM module if it's not already present (it will already be
// present if the input file is an LLVM IR/BC file).
if (!llvmModule)
GenerateLLVMIR();
// Create `Target`
std::string error;
const std::string &theTriple = llvmModule->getTargetTriple();
const llvm::Target *theTarget =
llvm::TargetRegistry::lookupTarget(theTriple, error);
// TODO: Make this a diagnostic once `flang-new` can consume LLVM IR files
// (in which users could use unsupported triples)
assert(theTarget && "Failed to create Target");
// Create `TargetMachine`
std::unique_ptr<llvm::TargetMachine> TM(
theTarget->createTargetMachine(theTriple, /*CPU=*/"",
/*Features=*/"", llvm::TargetOptions(), llvm::None));
[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
assert(TM && "Failed to create TargetMachine");
llvmModule->setDataLayout(TM->createDataLayout());
// 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
// 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
// updated to use it).
std::unique_ptr<llvm::raw_pwrite_stream> os;
if (ci.IsOutputStreamNull()) {
// Get the output buffer/file
switch (action) {
case BackendActionTy::Backend_EmitAssembly:
os = ci.CreateDefaultOutputFile(
/*Binary=*/false, /*InFile=*/GetCurrentFileOrBufferName(), "s");
break;
case BackendActionTy::Backend_EmitObj:
os = ci.CreateDefaultOutputFile(
/*Binary=*/true, /*InFile=*/GetCurrentFileOrBufferName(), "o");
break;
}
if (!os) {
unsigned diagID = ci.diagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "failed to create the output file");
ci.diagnostics().Report(diagID);
return;
}
}
// 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(theTriple);
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 = (action == BackendActionTy::Backend_EmitAssembly)
? llvm::CodeGenFileType::CGFT_AssemblyFile
: llvm::CodeGenFileType::CGFT_ObjectFile;
if (TM->addPassesToEmitFile(CodeGenPasses,
ci.IsOutputStreamNull() ? *os : ci.GetOutputStream(), nullptr,
cgft)) {
unsigned diagID =
ci.diagnostics().getCustomDiagID(clang::DiagnosticsEngine::Error,
"emission of this file type is not supported");
ci.diagnostics().Report(diagID);
return;
}
// Run the code-gen passes
CodeGenPasses.run(*llvmModule);
[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->instance();
unsigned DiagID =
ci.diagnostics().getCustomDiagID(clang::DiagnosticsEngine::Warning,
"Use `-init-only` for testing purposes only");
ci.diagnostics().Report(DiagID);
}
void PluginParseTreeAction::ExecuteAction() {}
void DebugDumpPFTAction::ExecuteAction() {
CompilerInstance &ci = this->instance();
if (auto ast = Fortran::lower::createPFT(
*ci.parsing().parseTree(), ci.semantics().context())) {
Fortran::lower::dumpPFT(llvm::outs(), *ast);
return;
}
unsigned DiagID = ci.diagnostics().getCustomDiagID(
clang::DiagnosticsEngine::Error, "Pre FIR Tree is NULL.");
ci.diagnostics().Report(DiagID);
}