aboutsummaryrefslogtreecommitdiff
path: root/flang/lib/Frontend/CompilerInvocation.cpp
AgeCommit message (Collapse)AuthorFilesLines
2023-02-07[flang] add -fstack-arrays flagTom Eccles1-0/+5
The implementation of -fstack-arrays was added in https://reviews.llvm.org/D140415 The new macro BoolOptionWithoutMarshalling in Options.td avoids generating code to store the flags in clang data structures. For example, writing something like defm stack_arrays : BoolOption<"f", "stack-arrays", CodeGenOpts<"StackArrays">, [...] Would generate code referring to `clang::CodeGenOpts::StackArrays`, which does not exist. Differential Revision: https://reviews.llvm.org/D140972
2023-01-31[flang][driver] Add support for -embed-offload-object flag in flangJan Sjodin1-0/+5
This patch adds support for the -embed-offload-object flag to embed offloading binaries in host code. This flag is identical to the clang flag with the same name. Differential Revision: https://reviews.llvm.org/D142244 Reviewed By: awarzynski, jhuber6
2023-01-07[flang] Use std::optional instead of llvm::Optional (NFC)Kazu Hirata1-1/+1
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h". This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-07[flang] Add #include <optional> (NFC)Kazu Hirata1-0/+1
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>. I'll post a separate patch to actually replace llvm::Optional with std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-09[flang] Add -ffast-math and -OfastTom Eccles1-0/+10
clang -cc1 accepts -Ofast. I did not add it to flang -fc1 because this seems redundant because the compiler driver will always resolve -Ofast into -O3 -ffast-math (I added a test for this). -menable-infs is removed from the frontend-forwarding test because if all of the fast-math component flags are present, these will be resolved into the fast-math flag. Instead -menable-infs is tested in the fast-math test. Specifying -ffast-math to the compiler driver causes linker invocations to include crtfastmath.o. RFC: https://discourse.llvm.org/t/rfc-the-meaning-of-ofast/66554 Differential Revision: https://reviews.llvm.org/D138675
2022-12-03[flang] Use std::nullopt instead of None (NFC)Kazu Hirata1-1/+1
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-02[Flang][Driver] Handle target CPU and featuresUsman Nadeem1-0/+8
This patch: - Adds target-feature and target-cpu to FC1Options. - Moves getTargetFeatures() from Clang.cpp to CommonArgs.cpp. - Processes target cpu and features in the flang driver. Right now features are only added for AArch64/x86 because I only did basic testing on them but it should generally work for others as well. Option handling is similar to clang. - Adds appropriate structures in TargetOptions and passes them to the target machine. What's missing: - Adding the CPU info and the features as attributes in the LLVM IR module. - Processing target specific flags, e.g. SVE vector bits for AArch64, ABI etc. Differential Revision: https://reviews.llvm.org/D137995 Change-Id: Ib081a74ea98617674845518a5d2754edba596418
2022-11-30[flang] fix unused variablesTom Eccles1-12/+6
2022-11-29[flang] Remove warnings that fast-math options are unimplementedTom Eccles1-9/+0
These are now fully implemented, see https://reviews.llvm.org/D137390 https://reviews.llvm.org/D137391 https://reviews.llvm.org/D137456 https://reviews.llvm.org/D137580 https://reviews.llvm.org/D137602 https://reviews.llvm.org/D138048 These flags are still tested in flang/test/Driver/frontend-forwarding.f90 and flang/test/Lower/fast-math-arithmetic.f90 Differential revision: https://reviews.llvm.org/D138907
2022-11-25[flang] Remove debug optionValentin Clement1-1/+0
Remove debug option added by mistake in D138587
2022-11-24[flang] Adapt descriptor codegen to support unlimited polymorphic entitiesValentin Clement1-0/+1
Code generation to create and populate the descriptor (element size and type code) is based on the boxed result type. This does not work well with unlimited polymorphic entities since the fir type does not represent what is actually emboxed or reboxed. In the case of emboxing, the input type will be used to populate the descriptor element size and type code. When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the element size and type code is retrieve from the input box. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D138587
2022-11-10[flang] Add -fpass-plugin option to flangTarun Prabhu1-0/+3
This patch adds the -fpass-plugin option to flang which dynamically loads LLVM passes from the shared object passed as the argument to the flag. The behavior of the option is designed to replicate that of the same option in clang and thus has the same capabilities and limitations. Features: Multiple instances of -fpass-plugin=path-to-file can be specified and each of the files will be loaded in that order. The flag can be passed to both flang-new and flang-new -fc1. The flag will be listed when the -help flag is passed to both flang-new and flang-new -fc1. It will also be listed when the --help-hidden flag is passed. Limitations: Dynamically loaded plugins are not supported in clang on Windows and are not supported in flang either. Addenda: Some minor stylistic changes are made in the files that were modified to enable this functionality. Those changes make the naming of functions more consistent, but do not change any functionality that is not directly related to enabling -fpass-plugin. Differential Revision: https://reviews.llvm.org/D129156
2022-11-09[flang] Propagate more FastMath flags to lowering.Slava Zakharin1-1/+6
Plugged in propagation of nnan/nsz/arcp/afn/reassoc related options to lowering/FirOpBuilder. Reviewed By: jeanPerier, tblah, awarzynski Differential Revision: https://reviews.llvm.org/D137580
2022-11-08[Driver] Refactor err_drv_unsupported_option_argument call sites to use ↵Fangrui Song1-1/+1
llvm::opt::Arg::getSpelling For `-foo=bar`, getSpelling return `-foo=` which is exactly what we need from the diagnostic. Drop `-` from the err_drv_unsupported_option_argument template. This change makes `--` long option diagnostics more convenient. Reviewed By: lenary Differential Revision: https://reviews.llvm.org/D137659
2022-11-07[flang] Configure FirOpBuilder based on math driver options.Slava Zakharin1-1/+11
Added MathOptionsBase to share fastmath config between different components. Frontend driver translates LangOptions into MathOptionsBase. FirConverter configures FirOpBuilder using MathOptionsBase config passed to it via LoweringOptions. Depends on D137390 Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D137391
2022-11-04[flang] add -f[no-]reciprocal-mathTom Eccles1-0/+6
Only add the option processing and store the result. No attributes are added to FIR yet. Differential Revision: https://reviews.llvm.org/D137330
2022-11-04[flang] Add -f[no-]associative-math and -mreassociateTom Eccles1-0/+6
Only add the option processing and store the result. No attributes are added to FIR yet. Clang only forwards -mreassociate if (AssociativeMath && !SignedZeros && !TrappingMath) Flang doesn't have -f[no-]trapping-math, so this part of the condition has been omitted. !TrappingMath is the default. Differential Revision: https://reviews.llvm.org/D137329
2022-11-04[flang] Add -f[no-]signed-zerosTom Eccles1-0/+6
Only add the option processing and store the result. No attributes are added to FIR yet. Differential Revision: https://reviews.llvm.org/D137328
2022-11-04[flang] Add -f[no-]approx-funcTom Eccles1-0/+6
Only add the option processing and store the result. No attributes are added to FIR yet. Differential Revision: https://reviews.llvm.org/D137326
2022-11-04[flang] Add -f[no-]honor-nans and -menable-no-nansTom Eccles1-0/+6
Only add the option processing and store the result. No attributes are added to FIR yet. Differential Revision: https://reviews.llvm.org/D137325
2022-11-03[Flang] Run clang-format on all flang filesPeter Steinfeld1-33/+38
This will make it easier for me to do reviews. Differential Revision: https://reviews.llvm.org/D137291
2022-11-03[flang] Add -f[no-]honor-infinities and -menable-no-infsTom Eccles1-0/+6
Only add the option processing and store the result. No attributes are added to FIR yet. This patch follows Clang in forwarding -fno-honor-infinities as -menable-no-infs. Reviewed By: kiranchandramohan awarzynski vzakhari Differential Revision: https://reviews.llvm.org/D137072
2022-10-31[flang] Add -ffp-contract option processingTom Eccles1-0/+38
Only add the option processing and store the result. No attributes are added to FIR yet. Only the "off" and "fast" options are supported. "fast-honor-pragmas" is not applicable because we do not implement `#pragma clang fp contract()` in Fortran [1]. "on" is not supported because it is unclear how to fuse only within individual statements. gfortran also does not implement "on": treating it as an "off". Currently the default value is "off" to preserve existing behavior. gfortran uses "fast" by default and that may be the right thing for flang-new after further discussion in the future, but that can be changed separately. gfortran's documentation is available [[ https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html | here ]]. [1] https://clang.llvm.org/docs/LanguageExtensions.html#extensions-to-specify-floating-point-flags Reviewed By: vzakhari, awarzynski Differential Revision: https://reviews.llvm.org/D136080
2022-10-27[flang] Remove debug flag added in D136824Valentin Clement1-1/+0
2022-10-27[flang] Carry dynamic type when emboxing polymorphic pointerValentin Clement1-0/+1
In order to be passed as passed-object in the dynamic dispatch, the polymorphic pointer entity are emboxed. In this process, the dynamic type must be preserve and pass to fir.embox as the tdesc operand. This patch introduce a new ExtendedValue that allow to carry over the dynamic type when the value is unboxed. Depends on D136820 Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D136824
2022-10-14[Flang] Adjust preprocessing to build modules correctlyPeter Steinfeld1-3/+7
Several module files in .../llvm-project/flang/module check for the existence of the macro "__x86_64__" to conditionally compile Fortran code. Unfortunately, this macro was not being defined anywhere. This patch fixes that for compilations targeting 64 bit x86 machines. I made the following changes -- -- Removed the test for 32 bit X86 targets. The rest of the compiler and runtime do not support X86 32 bits. -- Added predefined macros to define "__x86_64__" and "__x86__64" to be 1 when the target architecture is 64 bit x86 and the "-cpp" option is on the command line. -- Changed the cmake file for creating the Fortran module files to use the "-cpp" option so that the macro "__x86_64__" will be defined when building the module files. -- Added a test. Differential Revision: https://reviews.llvm.org/D135810
2022-10-12[Flang] Add -fconvert option to swap endianness for unformatted files.Jonathon Penix1-0/+22
To accomplish this, this patch creates an optional list of environment variable default values to be set by the runtime to allow directly using the existing runtime implementation of FORT_CONVERT for I/O conversions.
2022-10-05Revert "[flang] Add -fpass-plugin option to Flang frontend"Mats Petersson1-3/+0
This reverts commit 43fe6f7cc35ded691bbc2fa844086d321e705d46. Reverting this as CI breaks. To reproduce, run check-flang, and it will fail with an error saying .../lib/Bye.so not found in pass-plugin.f90
2022-10-04[flang] Add -fpass-plugin option to Flang frontendTarun Prabhu1-0/+3
Add the -fpass-plugin option to flang which dynamically loads LLVM passes from the shared object passed as the argument to the flag. The behavior of the option is designed to replicate that of the same option in clang and thus has the same capabilities and limitations. - Multiple instances of -fpass-plugin=path-to-file can be specified and each of the files will be loaded in that order. - The flag can be passed to both flang-new and flang-new -fc1. Differential Revision: https://reviews.llvm.org/D129156
2022-10-03[flang] Make real type of kind 10 target dependentPeixin Qiao1-0/+8
The real(10) is supported on x86_64. On aarch64, the value of selected_real_kind(16) should be 16 rather than 10 since real(10) is not supported on x86_64. Previously, the real type support check is not target dependent. Support it now through the target triple information. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D134021
2022-10-02Revert "[flang] Make real type of kind 10 target dependent"Peixin Qiao1-8/+0
This reverts commit d11e406e369fc90be5e2e2a0798ea7b7d2625882.
2022-10-02[flang] Make real type of kind 10 target dependentPeixin Qiao1-0/+8
The real(10) is supported on x86_64. On aarch64, the value of selected_real_kind(16) should be 16 rather than 10 since real(10) is not supported on x86_64. Previously, the real type support check is not target dependent. Support it now through the target triple information. Reviewed By: clementval Differential Revision: https://reviews.llvm.org/D134021
2022-08-27[flang] Simplify string comparisons (NFC)Kazu Hirata1-1/+1
Identified with readability-string-compare.
2022-08-22[Flang][Driver] Add support for PICUsman Nadeem1-0/+33
This patch does the following: - Consumes the PIC flags (fPIC/fPIE/fropi/frwpi etc) in flang-new. tools::ParsePICArgs() in ToolChains/CommonArgs.cpp is used for this. - Adds FC1Option to "-mrelocation-model", "-pic-level", and "-pic-is-pie" command line options. - Adds the above options to flang/Frontend/CodeGenOptions' data structure. - Sets the relocation model in the target machine, and - Sets module flags for the respective PIC/PIE type in LLVM IR. I have tried my best to replicate how clang does things. Differential Revision: https://reviews.llvm.org/D131533 Change-Id: I68fe64910be28147dc5617826641cea71b92d94d
2022-08-05[flang] Propagate lowering options from driver.Slava Zakharin1-0/+9
This commit addresses concerns raised in D129497. Propagate lowering options from driver to expressions lowering via AbstractConverter instance. A single use case so far is using optimized TRANSPOSE lowering with O1/O2/O3. bbc does not support optimization level switches, so it uses default LoweringOptions (e.g. optimized TRANSPOSE lowering is enabled by default, but an engineering -opt-transpose=false option can still override this). Differential Revision: https://reviews.llvm.org/D130204
2022-07-27[flang] Support the color diagnostics on scanning, parsing, and semanticsPeixin Qiao1-0/+3
The options -f{no-}color-diagnostics have been supported in driver. This supports the behaviors in scanning, parsing, and semantics, and the behaviors are exactly the same as the driver. To illustrate the added behaviour, consider the following input file: ```! file.f90 program m integer :: i = k end ``` In the following invocations, "error: Must be a constant value" _will be_ formatted: ``` $ flang-new file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k ``` Note that "error: Semantic errors in file.f90" is also formatted, which is supported in https://reviews.llvm.org/D126164. Also note that only "error", "warning" and "portability" are formatted. Check the following input file: ```! file2.f90 program m integer :: i = end ``` ``` $ flang-new test2.f90 error: Could not parse test2.f90 ./test2.f90:2:11: error: expected '(' integer :: i = ^ ./test2.f90:2:3: in the context: statement function definition integer :: i = ^ ... ``` The "error: Could not parse test2.f90" and "error: expected '('" are formatted. Others such as "in the context" are not formatted yet, which may or may not be supported. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D126166
2022-07-20[flang][driver] Fix opt-level option parsingAndrzej Warzynski1-3/+20
This update makes sure that `flang-new -O2 -O0` will run at `-O0` rather than `-O2`. This bug was identified and originally fixed by Vyacheslav Zakharin in https://reviews.llvm.org/D130035. I've extracted the fix into a separate patch. co-authored by: Vyacheslav Zakharin <vyacheslav.p.zakharin@intel.com> Differential Revision: https://reviews.llvm.org/D130104
2022-06-27[flang][driver] Add support for `-O{0|1|2|3}`Andrzej Warzynski1-0/+15
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-22[flang][Driver] Refine _when_ driver diagnostics are formattedPeixin Qiao1-7/+11
This patch refines //when// driver diagnostics are formatted so that `flang-new` and `flang-new -fc1` behave consistently with `clang` and `clang -cc1`, respectively. This change only applies to driver diagnostics. Scanning, parsing and semantic diagnostics are separate and not covered here. **NEW BEHAVIOUR** To illustrate the new behaviour, consider the following input file: ```! file.f90 program m integer :: i = k end ``` In the following invocations, "error: Semantic errors in file.f90" _will be_ formatted: ``` $ flang-new file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k $ flang-new -fc1 -fcolor-diagnostics file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k ``` However, in the following invocations, "error: Semantic errors in file.f90" _will not be_ formatted: ``` $ flang-new -fno-color-diagnostics file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k $ flang-new -fc1 file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k ``` Before this change, none of the above would be formatted. Note also that the default behaviour in `flang-new` is different to `flang-new -fc1` (this is consistent with Clang). **NOTES ON IMPLEMENTATION** Note that the diagnostic options are parsed in `createAndPopulateDiagOpt`s in driver.cpp. That's where the driver's `DiagnosticEngine` options are set. Like most command-line compiler driver options, these flags are "claimed" in Flang.cpp (i.e. when creating a frontend driver invocation) by calling `getLastArg` rather than in driver.cpp. In Clang's Options.td, `defm color_diagnostics` is replaced with two separate definitions: `def fcolor_diagnostics` and def fno_color_diagnostics`. That's because originally `color_diagnostics` derived from `OptInCC1FFlag`, which is a multiclass for opt-in options in CC1. In order to preserve the current behaviour in `clang -cc1` (i.e. to keep `-fno-color-diagnostics` unavailable in `clang -cc1`) and to implement similar behaviour in `flang-new -fc1`, we can't re-use `OptInCC1FFlag`. Formatting is only available in consoles that support it and will normally mean that the message is printed in bold + color. Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Reviewed By: rovka Differential Revision: https://reviews.llvm.org/D126164
2022-06-10[flang][driver] Make `flang-new -fc1` accept MLIR filesAndrzej Warzynski1-1/+3
This relatively small change will allow Flang's frontend driver, `flang-new -fc1`, to consume and parse MLIR files. Semantically (i.e. from user's perspective) this is identical to reading LLVM IR files. Two file extensions are associated with MLIR files: .fir and .mlir. Note that reading MLIR files makes only sense when running one of the code-generation actions, i.e. when using one of the following action flags: -S, -emit-obj, -emit-llvm, -emit-llvm-bc. The majority of tests that required `tco` to run are updated to also run with `flang-new -fc1`. A few tests are updated to use `fir-opt` instead of `tco` (that's the preferred choice when testing a particular MLIR pass). basic-program.fir is not updated as that test is intended to verify the behaviour of `tco` specifically. Differential Revision: https://reviews.llvm.org/D126890
2022-06-10[flang][driver] Fix support for `-x`Andrzej Warzynski1-1/+4
Until now, `-x` wasn't really taken into account in Flang's compiler and frontend drivers. `flang-new` and `flang-new -fc1` only recently gained powers to consume inputs other than Fortran files and that's probably why this hasn't been noticed yet. This patch makes sure that `-x` is supported correctly and consistently with Clang. To this end, verification is added when reading LLVM IR files (i.e. IR modules are verified with `llvm::verifyModule`). This way, LLVM IR parsing errors are correctly reported to Flang users. This also aids testing. With the new functionality, we can verify that `-x ir` breaks compilation for e.g. Fortran files and vice-versa. Tests are updated accordingly. Differential Revision: https://reviews.llvm.org/D127207
2022-05-14[flang][driver] Switch to the MLIR coding style in the driver (nfc)Andrzej Warzynski1-82/+88
This patch re-factors the driver code in LLVM Flang (frontend + compiler) to use the MLIR style. For more context, please see: https://discourse.llvm.org/t/rfc-coding-style-in-the-driver/ Most changes here are rather self-explanatory. Accessors are renamed to be more consistent with the rest of LLVM (e.g. allSource --> getAllSources). Additionally, MLIR clang-tidy files are added in the affected directories. clang-tidy and clang-format files were copied from MLIR. Small additional changes are made to silence clang-tidy/clang-format warnings. [1] https://mlir.llvm.org/getting_started/DeveloperGuide/ Differential Revision: https://reviews.llvm.org/D125007
2022-05-04[flang][driver] Define the default frontend driver tripleAndrzej Warzynski1-1/+14
*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-27[flang][driver] NFC: Make code more in line with LLVM styleAndrzej Warzynski1-3/+0
This patch basically implements [1] in ExecuteCompilerInvocation.cpp. It also: * replaces `CreateFrontendBaseAction` with `CreateFrontendAction` (only one method is needed ATM, this change removes the extra indirection) * removes `InvalidAction` from the `ActionKind` enum (I don't think it adds much and keeping it would mean adding a new void case in `CreateFrontendAction`) * sets the default frontend action in FrontendOptions.h to `ParseSyntaxOnly` (note that this is still overridden independently in `ParseFrontendArg` in CompilerInvocation.cpp) No new functionality is added, hence no tests. [1] https://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations Differential Revision: https://reviews.llvm.org/D124245
2022-04-14[flang][driver] Add support for `-mmlir`Andrzej Warzynski1-0/+3
The semantics of `-mmlir` are identical to `-mllvm`. The only notable difference is that `-mmlir` options should be forwarded to MLIR rather than LLVM. Note that MLIR llvm::cl options are lazily constructed on demand (see the definition of options in PassManagerOptions.cpp). This means that: * MLIR global options are only visible when explicitly initialised and displayed only when using `-mmlir --help`, * Flang and LLVM global options are always visible and displayed when using either `-mllvm -help` or `-mmlir --help`. In other words, `-mmlir --help` is a superset of `-mllvm --help`. This is not ideal, but we'd need to refactor all option definitions in Flang and LLVM to improve this. I suggesting leaving this for later. Differential Revision: https://reviews.llvm.org/D123297
2022-04-13[flang][driver] Add support for generating LLVM bytecode filesAndrzej Warzynski1-0/+3
Support for generating LLVM BC files is added in Flang's compiler and frontend drivers. This requires the `BitcodeWriterPass` pass to be run on the input LLVM IR module and is implemented as a dedicated frontend aciton. The new functionality as seen by the user (compiler driver): ``` flang-new -c -emit-llvm file.90 ``` or (frontend driver): ``` flang-new -fc1 -emit-llvm-bc file.f90 ``` The new behaviour is consistent with `clang` and `clang -cc1`. Differential Revision: https://reviews.llvm.org/D123211
2022-04-10[Driver] Simplify -f[no-]diagnostics-color handling. NFCFangrui Song1-4/+2
Make them aliases for -f[no-]color-diagnostics.
2022-04-05[flang][cmake] Make CMake copy "omp_lib.h" into the build directoryAndrzej Warzynski1-0/+14
Any header or module file in the Flang source directory is of no use to the compiler unless it is copied into the build directory. Indeed, all compiler search paths are relative to the compiler executable (flang-new in our case). Hence, "omp_lib.h" should be copied into the build directory alongside other compiler-provided files that can be "included" (header files) or "used" (module files). For now, "omp_lib.h" is copied into "<build-dir>/include/flang/OpenMP". We may decide to change this in future. For example, Clang copies a bunch of runtime headers into “<build-dir>/lib/clang/<version-number>”. We could also consider using a similar header from a different sub-project. Flang's driver search path is updated accordingly. A rule for "installing" the "omp_lib.h" header is _yet to be added_ (we will also need to determine the suitable location for this). Differential Revision: https://reviews.llvm.org/D122015
2022-03-16[flang][driver] Add support for `-mllvm`Andrzej Warzynski1-0/+2
This option is added in both `flang-new` (the compiler driver) and `flang-new -fc1` (the frontend driver). The semantics are consistent with `clang` and `clang -cc1`. As Flang does not run any LLVM passes when invoked with `-emit-llvm` (i.e. `flang-new -S -emit-llvm <file>`), the tests use `-S`/`-c`/`-emit-obj` instead. These options require an LLVM backend to be run by the driver to generate the output (this makese `-mllvm` relevant here). Differential Revision: https://reviews.llvm.org/D121374
2022-03-09[flang][driver] Add support for -S and implement -c/-emit-objAndrzej Warzynski1-0/+3
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