This patch renames the `OpenMPIRBuilderConfig` flags to reduce confusion over
their meaning. `IsTargetCodegen` becomes `IsGPU`, whereas `IsEmbedded` becomes
`IsTargetDevice`. The `-fopenmp-is-device` compiler option is also renamed to
`-fopenmp-is-target-device` and the `omp.is_device` MLIR attribute is renamed
to `omp.is_target_device`. Getters and setters of all these renamed properties
are also updated accordingly. Many unit tests have been updated to use the new
names, but an alias for the `-fopenmp-is-device` option is created so that
external programs do not stop working after the name change.
`IsGPU` is set when the target triple is AMDGCN or NVIDIA PTX, and it is only
valid if `IsTargetDevice` is specified as well. `IsTargetDevice` is set by the
`-fopenmp-is-target-device` compiler frontend option, which is only added to
the OpenMP device invocation for offloading-enabled programs.
Differential Revision: https://reviews.llvm.org/D154591
This flag enables Fortran 2003 polymorphism. It is marked experimental
and not included in --help.
Reviewed By: tblah, awarzynski
Differential Revision: https://reviews.llvm.org/D153281
OpenMP standard (section 3.3 for OpenMP 5.2) requires that _OPENMP macro
contains release date of given OpenMP standard version.
Differential Revision: https://reviews.llvm.org/D151083
Reviewed By: kiranchandramohan
In review for https://reviews.llvm.org/D146278, @vzakhari asked to
separate -emit-fir and -emit-hlfir. This will allow FIR to be easily
outputted after the HLFIR passes have been run.
The new semantics are as follows:
| Action | -flang-experimental-hlfir? | Result |
| =========== | ========================== | =============================== |
| -emit-hlfir | N | Outputs HLFIR |
| -emit-hlfir | Y | Outputs HLFIR |
| -emit-fir | N | Outputs FIR, using old lowering |
| -emit-fir | Y | Outputs FIR, lowering via HLFIR |
A patch for bbc will follow.
Differential Revision: https://reviews.llvm.org/D151088
This revision implements the Fortran intrinsic procedures COMPILER_VERSION and COMPILER_OPTIONS from the iso_fortran_env module.
To be able to set the COMPILER_OPTIONS string according to the original compiler driver invocation, a string is passed to the frontend driver using the environment variable FLANG_COMPILER_OPTIONS_STRING, for lack of a better mechanism.
Fixes#59233
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D140524
This patch adds flag -fopenmp-version to the Flang frontend and bbc tool.
This flag is lowered to MLIR OpenMP flag attribute.
Differential Revision: https://reviews.llvm.org/D150354
Reviewed By: kiranchandramohan
Establish a set of optional usage warnings, and enable some
only in "-pedantic" mode that, in our subjective experience
with application codes, seem to issue frequently without
indicating usage that really needs to be corrected. By default,
with this patch the compiler should appear to be somewhat less
persnickety but not less informative.
Differential Revision: https://reviews.llvm.org/D150710
This patch ports the fopenmp-host-ir-file-path flag from Clang to Flang-new, this flag
is added by the driver to the device pass when doing two phase compilation (device + host).
This flag is then applied to the module when compiling during the OpenMP device phase.
This file can then be utilised during lowering of the OpenMP dialect to LLVM-IR, which
allows the device and host to maintain 1:1 mapping of OpenMP metadata for variables
during lowering via the OpenMPIRBuilders loadOffloadInfoMetadata facilities
(which is used for declare target and I believe target regions as well).
Reviewer: awarzynski
Differential Revision: https://reviews.llvm.org/D148038
This patch ports OpenMP RTL flags from the shared Clang compiler
options to Flang. As well as adding a limited subset to bbc.
This patch enables the flags below (and any equals or inverse variants)
for Flang that exist in Clang:
-fopenmp-target-debug
-fopenmp-assume-threads-oversubscription
-fopenmp-assume-teams-oversubscription
-fopenmp-assume-no-nested-parallelism
-fopenmp-assume-no-thread-state
For the bbc tool it only utilises the primary variants to minimize
additional complexity in the tool.
The patch also provides FlagAttr generation from these flags. Which
will be lowered to LLVM-IR in a subsequent patch.
Reviewers: kiranchandramohan, awarzynski
Differential Revision: https://reviews.llvm.org/D147324
While a pass exists to generate basic debug information, currently there is not a corresponding flag to enable it.
This patch adds support for activating this pass at any debug level >= -g1, as well as emiting a warning for higher levels that the functionality is not yet fully implemented.
This patch also adds -g and -gline-tables-only to appear when `flang-new` --help is run
Depends on D142347.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D146814
This patch adds support for producing MLIR files when using -save-temps on
flang. One MLIR file will be produced before lowering and optimization passes,
containing the operations produced by the PFT-to-MLIR lowering bridge, and
another at the end of the process, just before LLVM IR generation.
This is accomplished by forwarding the -save-temps flag from the driver to the
frontend, and modifying it to output MLIR files accordingly.
Differential Revision: https://reviews.llvm.org/D146075
This flag instructs flang-new to use the new HLFIR lowering. It is
marked as experimental and not included in --help.
This was added to make it more convenient to test the performance of
code generated by the HLFIR lowering.
Extra diffs are from running clang-format on CLOptions.inc (which was
being forced by CI).
Differential Revision: https://reviews.llvm.org/D146278
Thin and full LTO modes use different pre-link pipelines compared to
regular compilation. This patch adds support for calling those pipelines.
This patch closely mimics Clang's implementation with the exception that I
changed the codegen option name from `PrepareForLTO` to `PrepareForFullLTO`
to be more precise.
With this patch:
- Compilation for full LTO should be as we expect (except possibly
missing optimizations enabled by module summaries which we do not
produce yet).
- thinLTO uses the correct prelink pipeline but will use the postlink
backend for fullLTO due to missing metadata and summary in the llvm
module. I have added a warning regarding this: `flang-new: warning: the
option '-flto=thin' is a work in progress`.
Differential Revision: https://reviews.llvm.org/D142420
Change-Id: I6b94b775b5b8e93340e520c5cd4bf60834b2e209
Adds the -fopenmp-is-device flag to bbc and Flang's -fc1 (but not flang-new) and in addition adds an omp.is_device attribute onto the module when fopenmp is passed, this is a boolean attribute that is set to false or true dependent on if fopenmp-is-device is specified alongside the fopenmp flag on the commandline when invoking flang or bbc.
Reviewers:
awarzynski
kiranchandramohan
Differential Revision: https://reviews.llvm.org/D144864
This PR makes flang emit a warning when the user passes an unsupported gfortran warning flag in as a CLI arg. This PR also checks each `-W` argument instead of just looking at the last one passed in.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D143301
The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
