This seems to be the consensus in
https://github.com/flang-compiler/f18-llvm-project/issues/1316
The patch adds ExternalNameConversion to the default FIR CodeGen pass
pipeline, right before the FIRtoLLVM pass. It also adds a flag to
optionally disable it, and sets it in `tco`. In other words, `flang-new`
and `flang-new -fc1` will both run the pass by default, whereas `tco`
will not, so none of the tests need to be updated.
Differential Revision: https://reviews.llvm.org/D121171
This patch adds 2 missing items required for `flang-new` to be able to
generate executables:
1. The Fortran_main runtime library, which implements the main entry
point into Fortran's `PROGRAM` in Flang,
2. Extra linker flags to include Fortran runtime libraries (e.g.
Fortran_main).
Fortran_main is the bridge between object files generated by Flang and
the C runtime that takes care of program set-up at system-level. For
every Fortran `PROGRAM`, Flang generates the `_QQmain` function.
Fortran_main implements the C `main` function that simply calls
`_QQmain`.
Additionally, "<driver-path>/../lib" directory is added to the list of
search directories for libraries. This is where the required runtime
libraries are currently located. Note that this the case for the build
directory. We haven't considered installation directories/targets yet.
With this change, you can generate an executable that will print `hello,
world!` as follows:
```bash
$ cat hello.f95
PROGRAM HELLO
write(*, *) "hello, world!"
END PROGRAM HELLO
$ flang-new -flang-experimental-exec hello.f95
./a.out
hello, world!
```
NOTE 1: Fortran_main has to be a static library at all times. It invokes
`_QQmain`, which is the main entry point generated by Flang for the
given input file (you can check this with `flang-new -S hello.f95 -o - |
grep "Qmain"`). This means that Fortran_main has an unresolved
dependency at build time. The linker will allow this for a static
library. However, if Fortran_main was a shared object, then the linker
will produce an error: `undefined symbol: `_QQmain`.
NOTE 2: When Fortran runtime libraries are generated as shared libraries
(excluding Fortran_main, which is always static), you will need to
tell the dynamic linker (by e.g. tweaking LD_LIBRARY_PATH) where to look
for them when invoking the executables. For example:
```bash
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<flang-build-dir>/lib/ ./a.out
```
NOTE 3: This feature is considered experimental and currently guarded
with a flag: `-flang-experimental-exec`.
Differential Revision: https://reviews.llvm.org/D122008
[1] https://github.com/flang-compiler/f18-llvm-project
CREDITS: Fortran_main was originally written by Eric Schweitz, Jean
Perier, Peter Klausler and Steve Scalpone in the fir-dev` branch in [1].
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Peter Klausler <pklausler@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Steve Scalpone <sscalpone@nvidia.com
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
This patch adds a lowering test for the C
interoperability.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122307
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
The intrinsic module IEEE_ARITHMETIC must incorporate the public
names from the intrisic module IEEE_EXCEPTIONS. Rename IEEE_EXCEPTIONS
to __Fortran_ieee_exceptions so that it won't clash with the
nonintrinsic namespace, establish a new intrinic IEEE_EXCEPTIONS
module that USEs it, and add a USE to IEEE_ARITHMETIC.
Updated to use STREQUAL rather than ambiguous MATCHES in
the CMakeLists.txt file.
Differential Revision: https://reviews.llvm.org/D121490
The intrinsic module IEEE_ARITHMETIC must incorporate the public
names from the intrisic module IEEE_EXCEPTIONS. Rename IEEE_EXCEPTIONS
to __Fortran_ieee_exceptions so that it won't clash with the
nonintrinsic namespace, establish a new intrinic IEEE_EXCEPTIONS
module that USEs it, and add a USE to IEEE_ARITHMETIC.
Differential Revision: https://reviews.llvm.org/D121490
Add `-fopenacc` flag to the `bbc` tool.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D121117
Add `-fopenmp` flag to the `bbc` tool.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz, awarzynski
Differential Revision: https://reviews.llvm.org/D121118
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
The current StandardToLLVM conversion patterns only really handle
the Func dialect. The pass itself adds patterns for Arithmetic/CFToLLVM, but
those should be/will be split out in a followup. This commit focuses solely
on being an NFC rename.
Aside from the directory change, the pattern and pass creation API have been renamed:
* populateStdToLLVMFuncOpConversionPattern -> populateFuncToLLVMFuncOpConversionPattern
* populateStdToLLVMConversionPatterns -> populateFuncToLLVMConversionPatterns
* createLowerToLLVMPass -> createConvertFuncToLLVMPass
Differential Revision: https://reviews.llvm.org/D120778
MlirOptMain is currently awkwardly shoved into mlir/Support. This commit
moves it to the Tools/ directory, which is intended for libraries used to
implement tools.
Differential Revision: https://reviews.llvm.org/D121025
There is no reason for this file to be at the top-level, and
its current placement predates the Parser/ folder's existence.
Differential Revision: https://reviews.llvm.org/D121024
Currently if an operation requires additional verification, it specifies an inline
code block (`let verifier = "blah"`). This is quite problematic for various reasons, e.g.
it requires defining C++ inside of Tablegen which is discouraged when possible, but mainly because
nearly all usages simply forward to a static function `static LogicalResult verify(SomeOp op)`.
This commit adds support for a `hasVerifier` bit field that specifies if an additional verifier
is needed, and when set to `1` declares a `LogicalResult verify()` method for operations to
override. For migration purposes, the existing behavior is untouched. Upstream usages will
be replaced in a followup to keep this patch focused on the hasVerifier implementation.
One main user facing change is that what was one `MyOp::verify` is now `MyOp::verifyInvariants`.
This better matches the name this method is called everywhere else, and also frees up `verify` for
the user defined additional verification. The `verify` function when generated now (for additional
verification) is private to the operation class, which should also help avoid accidental usages after
this switch.
Differential Revision: https://reviews.llvm.org/D118742
Apply part of a pending patch for GCC 11 warnings, and
rework a piece of code, to dodge warnings on flag from
GCC 11 build bots exposed by a recent patch.
Applying without review to get bots working again; changes
also tested against GCC 9.3.0.
This patch enable lowering from Fortran to FIR for a basic empty
program. It brings all the infrastructure needed for that. As discussed
previously, this is the first patch for lowering and follow up patches
should be smaller.
With this patch we can lower the following code:
```
program basic
end program
```
To a the FIR equivalent:
```
func @_QQmain() {
return
}
```
Follow up patch will add lowering of more complex constructs.
Reviewed By: kiranchandramohan, schweitz, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D118436
`tco` does not generate machine code, so it does not require (machine)
code-gen related dependencies.
Differential Revision: https://reviews.llvm.org/D118112
tco is a tool to test the FIR to LLVM IR pipeline of the Flang compiler.
This patch update tco pipelines and adds the translation to LLVM IR.
A simple test is added to make sure the tool is working with a simple
FIR program.
More tests will be upstream in follow up patch from the fir-dev branch.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, awarzynski, schweitz, mehdi_amini
Differential Revision: https://reviews.llvm.org/D117781
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
tco is a tool to test the FIR to LLVM IR pipeline of the Flang compiler.
This patch update tco pipelines and adds the translation to LLVM IR.
A simple test is added to make sure the tool is working with a simple
FIR program.
More tests will be upstream in follow up patch from the fir-dev branch.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz, mehdi_amini
Differential Revision: https://reviews.llvm.org/D117781
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
As per https://github.com/flang-compiler/f18-llvm-project/issues/1344,
the `flang` bash script works fine with 4.4.19 and requiring
4.4.23 is too restrictive. Rather than keep updating the patch level,
this patch removes this particular check (so that it will only check the
major and minor versions instead).
As this is both rather straightforward and urgent, I'm merging this
without a review.
The `flang` wrapper script has been written in a relatively modern
version of Bash and it fails on systems with older versions. This patch
makes the script check the version of Bash being used to run it and
generates an error when unsupported version is used.
This was discussed in more detail in:
* https://github.com/flang-compiler/f18-llvm-project/issues/1344.
Many thanks to Anthony Cabrera for the suggestion and for identifying
the oldest version of Bash that we can use here.
Differential Revision: https://reviews.llvm.org/D116608
This patch updates the `flang` bash scripts to differentiate between
object files provided by the user and intermediate object files
generated by the script. The latter are an "implementation detail" that
should not be visible to the end user (i.e. deleted before the scripts
exits). The former should be preserved.
Fixes https://github.com/flang-compiler/f18-llvm-project/issues/1348
Differential Revision: https://reviews.llvm.org/D116590
Extracted from D99484. My new plan is to start from the outside and work
inward.
Reviewed By: stephenneuendorffer
Differential Revision: https://reviews.llvm.org/D115569
Clean up InitFIR.h file.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D111539
Co-authored-by: Valentin Clement <clementval@gmail.com>
Add the external name conversion pass needed for compiler
interoperability. This pass convert the Flang internal symbol name to
the common gfortran convention.
Clean up old passes without implementation in the Passes.ts file so
the project and fir-opt can build correctly.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D111057
Partition libFIROptimizer into smaller libraries that reflect the
structure. Adapt potential problems.
This patch is part of the upstreaming effort from fir-dev branch. It's a
building stone to upstreaming transformations.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D111055
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Partition libFIROptimizer into smaller libraries that reflect the
structure. Adapt potential problems.
This patch is part of the upstreaming effort from fir-dev branch. It's a
building stone to upstreaming transformations.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D111055
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Partition libFIROptimizer into smaller libraries that reflect the
structure. Adapt potential problems.
This patch is part of the upstreaming effort from fir-dev branch. It's a
building stone to upstreaming transformations.
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D111055
Rearrange the contents of __builtin_* module files a little and
make sure that semantics implicitly USEs the module __Fortran_builtins
before processing each source file. This ensures that the special derived
types for TEAM_TYPE, EVENT_TYPE, LOCK_TYPE, &c. exist in the symbol table
where they will be available for use in coarray intrinsic function
processing.
Update IsTeamType() to exploit access to the __Fortran_builtins
module rather than applying ad hoc name tests. Move it and some
other utilities from Semantics/tools.* to Evaluate/tools.* to make
them available to intrinsics processing.
Add/correct the intrinsic table definitions for GET_TEAM, TEAM_NUMBER,
and THIS_IMAGE to exercise the built-in TEAM_TYPE as an argument and
as a result.
Add/correct/extend tests accordingly.
Differential Revision: https://reviews.llvm.org/D110356
Introducing a plugin API and a simple HelloWorld Plugin example.
This patch adds the `-load` and `-plugin` flags to frontend driver and
the code around using custom frontend actions from within a plugin
shared library object.
It also adds to the Driver-help test to check the help option with the
updated driver flags.
Additionally, the patch creates a plugin-example test to check the
HelloWorld plugin example runs correctly. As part of this, a new CMake
flag (`FLANG_BUILD_EXAMPLES`) is added to allow the example to be built
and for the test to run.
This Plugin API has only been tested on Linux.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D106137
We are only adding this in `flang` - the bash wrapper script for the
driver. We don't have any specific plans to support `-M{fixed|free}` in
`flang-new` (i.e. the actual driver).
That feature was requested by one of our users.
Differential Revision: https://reviews.llvm.org/D107081
This patch removes `f18`, a.k.a. the old driver. It is being replaced
with the new driver, `flang-new`, which has reached feature parity with
`f18` a while ago. This was discussed in [1] and also in [2].
With this change, `FLANG_BUILD_NEW_DRIVER` is no longer needed and is
also deleted. This means that we are making the dependency on Clang permanent
(i.e. it cannot be disabled with a CMake flag).
LIT set-up is updated accordingly. All references to `f18` or `f18.cpp`
are either updated or removed.
The `F18_FC` variable from the `flang` bash script is replaced with
`FLANG_FC`. The former is still supported for backwards compatibility.
[1] https://lists.llvm.org/pipermail/flang-dev/2021-June/000742.html
[2] https://reviews.llvm.org/D103177
Differential Revision: https://reviews.llvm.org/D105811
This file was previously included transitively via `mlir/Transforms/Passes.h`, but the include has been removed from that file.
Differential Revision: https://reviews.llvm.org/D107455
Rename the current -E option to "-E -Xflang -fno-reformat".
Add a new Parsing::EmitPreprocessedSource() routine to convert the
cooked character stream output of the prescanner back to something
more closely resembling output from a traditional preprocessor;
call this new routine when -E appears.
The new -E output is suitable for use as fixed form Fortran source to
compilation by (one hopes) any Fortran compiler. If the original
top-level source file had been free form source, the output will be
suitable for use as free form source as well; otherwise there may be
diagnostics about missing spaces if they were indeed absent in the
original fixed form source.
Unless the -P option appears, #line directives are interspersed
with the output (but be advised, f18 will ignore these if presented
with them in a later compilation).
An effort has been made to preserve original alphabetic character case
and source indentation.
Add -P and -fno-reformat to the new drivers.
Tweak test options to avoid confusion with prior -E output; use
-fno-reformat where needed, but prefer to keep -E, sometimes
in concert with -P, on most, updating expected results accordingly.
Differential Revision: https://reviews.llvm.org/D106727
This patch only modifies `flang` - the bash wrapper script.
`-fopenmp`/`-fopenacc` are required to enable the OpenMP/OpenACC
extension in the frontend and to make sure that the required libraries
are linked when generating the final binary. This patch makes sure that
`-fopnemp`/`-fopenacc` is used for both unparsing and the code
generation (via the host compiler).
Differential Revision: https://reviews.llvm.org/D106871
`-Mfixed` is not supported by the new driver and hence
`flang`, the bash wrapper script, forwards it to the host compiler.
The forwarded options are used by the host compiler when compiling the
unparsed files. As the unparsed source files are always in the free
form, forwarding `-Mfixed` is problematic.
With this patch, `-Mfixed` (and `-Mfree` for consistency) will be
ignored altogether. The user will only see a warning. This is not a
particularly sound approach, but `flang` is only a temporary solution
for us and this workaround is a fair compromise.
Differential Revision: https://reviews.llvm.org/D106428
In the `flang` bash script, we need to be careful _when_ to use <output>
from `flang -c -o <output> <input>` when generating the relocatable
output file name.
In particular, we should use it in this case:
```compilation only
flang -c -o <output> <input>
```
but leave it for the final executable here:
```compile, assemble and link
flang -o <output> <input>
```
This change is implemented in `get_relocatable_name`.
I've also taken the liberty to fix how errors from sub-commands are
reported (without this change, `flang` always returns `0` on failure).
This is implemented in `main`.
Differential Revision: https://reviews.llvm.org/D105896
This patch makes sure that the base name of the temporary unparsed files
(generated by the `flang` bash script) are randomised and unique to a
particular invocation of the script. Otherwise, we cannot reliably run
the script in parallel.
Differential Revision: https://reviews.llvm.org/D106052
Currently, `flang -c file.f` generates `flang_unparsed_source_file_0.o`.
This is incorrect. This patch:
* simplifies the logic around output filename generation, and
* makes sure that `file.o` is produced instead of e.g.
`flang_unparsed_source_file_0.o` when using the `-c` flag
The output filename generation is moved to a dedicated function. I've
also made a few minor improvements, e.g. marked variables as local,
added comments, refined error messages.
Differential Revision: https://reviews.llvm.org/D105546
The bash wrapper script, `flang`, calls `flang-new -fc1` under the hood,
which does not support `--version` (this is consistent with `clang -cc1
--version`). This change is needed for `flang --version` to work as
expected.
Note that `flang --version` (the Flang bash wrapper script for the
compiler driver) gives rather minimal output compared to `flang-new
--version` (the Flang compiler driver). As the wrapper script is just a
temporary solution for us, this should be sufficient.
Differential Revision: https://reviews.llvm.org/D105352
Diana Picus