This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
This is part of an effort to migrate from llvm::Optional to
std::optional. This patch changes the way mlir-tblgen generates .inc
files, and modifies tests and documentation appropriately. It is a "no
compromises" patch, and doesn't leave the user with an unpleasant mix of
llvm::Optional and std::optional.
A non-trivial change has been made to ControlFlowInterfaces to split one
constructor into two, relating to a build failure on Windows.
See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Signed-off-by: Ramkumar Ramachandra <r@artagnon.com>
Differential Revision: https://reviews.llvm.org/D138934
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
hlfir.declare codegen generates a fir.declare, and may generate a
fir.embox/fir.rebox/fir.emboxchar if the base value does not convey
all the variable bounds and length parameter information.
Leave OPTIONAL as a TODO to keep this patch simple. It will require
making the embox/rebox optional to preserve the optionality aspects.
Differential Revision: https://reviews.llvm.org/D137789
Pass plugins are compiled and linked dynamically by default. Setting
`LLVM_${NAME}_LINK_INTO_TOOLS` to `ON` turns the project into a
statically linked extension. Projects like Polly can be used this way by
adding `-DLLVM_POLLY_LINK_INTO_TOOLS=ON` to the `cmake` command.
The changes in this patch makes the PassBuilder in Flang aware of
statically linked pass plugins, see the documentation for more details:
https://github.com/llvm/llvm-project/blob/main/llvm/docs/WritingAnLLVMNewPMPass.rst#id21
Differential Revision: https://reviews.llvm.org/D137673
Change-Id: Id1aa501dcb4821d0ec779f375cc8e8d6b0b92fce
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
The quad precision kind is defined as 8 by default in
flang/include/flang/Common/default-kinds.h. However, it should be target
dependent. This fixes the default quad precision kind when the target
is on X86_64.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D136581
This patch adds the basic dialect definition of the HLFIR dialect that
was described in https://reviews.llvm.org/D134285.
It adds the definition of the hlfir.expr type and related tests so that
it can be verified that the dialect is properly hooked up by the tools.
Operations will be added as progress is made in the expression
lowering update.
Differential Revision: https://reviews.llvm.org/D136328
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
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
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
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
The SemanticsContext is needed to analyze expression later in the
lowering for directive languages. This patch allows to keep a reference of
the SemanticsContext in the LoweringBridge.
Building block for D131765
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D131764
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
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
Try 2 to merge 4fbd1d6c872e8228f23a6e13914222af40ca6461.
Flang algebraic simplification pass will run algebraic simplification
rewrite patterns for Math/Complex/etc. dialects. It is enabled
under opt-for-speed optimization levels (i.e. for O1/O2/O3; Os/Oz will not
enable it).
With this change the FIR/MLIR optimization pipeline becomes affected
by the -O* optimization level switches. Until now these switches
only affected the middle-end and back-end.
Differential Revision: https://reviews.llvm.org/D130035
Flang algebraic simplification pass will run algebraic simplification
rewrite patterns for Math/Complex/etc. dialects. It is enabled
under opt-for-speed optimization levels (i.e. for O1/O2/O3; Os/Oz will not
enable it).
With this change the FIR/MLIR optimization pipeline becomes affected
by the -O* optimization level switches. Until now these switches
only affected the middle-end and back-end.
Differential Revision: https://reviews.llvm.org/D130035
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
