On Linux, PowerPC defines `int_fast16_t` and `int_fast32_t` as `long`.
Need to update the corresponding type, `c_int_fast16_t` and
`c_int_fast32_t` in `iso_c_binding` module so they are interoparable.
Polymorphic entity lowering status is good. The main remaining TODO is
to allow lowering of vector subscripted polymorphic entity, but this
does not deserve blocking all application using polymorphism.
Remove experimental option and enable lowering of polymorphic entity by
default.
`ConversionPatternRewriter` objects should not be constructed outside of
dialect conversions. Some IR modifications performed through a
`ConversionPatternRewriter` are reflected in the IR in a delayed fashion
(e.g., only when the dialect conversion is guaranteed to succeed). Using
a `ConversionPatternRewriter` outside of the dialect conversion is
incorrect API usage and can bring the IR in an inconsistent state.
Migration guide: Use `IRRewriter` instead of
`ConversionPatternRewriter`.
This change introduces the `addFIRExtensions` method to dynamically and
conditionally register dialect interfaces. As a use case of
`addFIRExtensions`, this change moves the static registration of
`FIRInlinerInterface` out of the constructor of `FIROpsDialect` to be
dynamically registered while loading the necessary MLIR dialects
required by Flang. This registration of `FIRInlinerInterface` is also
guarded by a boolean `addFIRInlinerInterface` which defaults to true.
---------
Co-authored-by: Vijay Kandiah <vkandiah@nvidia.com>
The implemented logic matches the logic used for Clang in emitting these
attributes. Although it's hoped that function attributes won't be needed
in the future (vs using fast math flags in individual IR instructions),
there are codegen differences currently with/without these attributes,
as can be seen in issues like #79257 or by hacking Clang to avoid
producing these attributes and observing codegen changes.
Introduce Code Object V6 in Clang, LLD, Flang and LLVM. This is the same
as V5 except a new "generic version" flag can be present in EFLAGS. This
is related to new generic targets that'll be added in a follow-up patch.
It's also likely V6 will have new changes (possibly new metadata
entries) added later.
Docs change are part of the follow-up patch #76955
This patch removes the omp.target module attribute, since the
information it held on the target CPU and features is available through
the fir.target_cpu and fir.target_features module attributes. Target
outlining during the MLIR to LLVM IR translation stage is updated, so
that these attributes, at that point available as llvm.func attributes,
are passed along to the newly created function.
This patch forwards the target CPU and features information from the
Flang frontend to MLIR func.func operation attributes, which are later
used to populate the target_cpu and target_features llvm.func
attributes.
This is achieved in two stages:
1. Introduce the `fir.target_cpu` and `fir.target_features` module
attributes with information from the target machine immediately after
the initial creation of the MLIR module in the lowering bridge.
2. Update the target rewrite flang pass to get this information from the
module and pass it along to all func.func MLIR operations, respectively
as attributes named `target_cpu` and `target_features`. These attributes
will be automatically picked up during Func to LLVM dialect lowering and
used to initialize the corresponding llvm.func named attributes.
The target rewrite and FIR to LLVM lowering passes are updated with the
ability to override these module attributes, and the `CodeGenSpecifics`
optimizer class is augmented to make this information available to
target-specific MLIR transformations.
This completes a full flow by which target CPU and features make it all
the way from compiler options to LLVM IR function attributes.
If `generateLLVMIR()` fails, we still continue using the module we
failed to generate which causes a seg fault if LLVM code-gen failed for
some reason or another. This commit fixes this issue.
Re-applies PR #78269 and adds LLVM and MLIR dependencies that were
missed in the PR. The missing libs were: `LLVMCore` & `MLIRIR`.
This reverts commit 4fc7506274.
This reverts commit 99cae9a44f.
Temporarily until I reproduce and fix a linker issue:
```
FAILED: tools/flang/unittests/Frontend/FlangFrontendTests
...
/usr/bin/ld: tools/flang/unittests/Frontend/CMakeFiles/FlangFrontendTests.dir/CodeGenActionTest.cpp.o: undefined reference to symbol '_ZN4llvm11LLVMContextC1Ev'
/usr/bin/ld: /work1/omp-nightly/build/git/trunk18.0/build/llvm-project/lib/libLLVMCore.so.18git: error adding symbols: DSO missing from command line
```
After #77905, setting -mvscale-min or -mvscale-max on targets other than
AArch64 and RISC-V should be an error now, so we no longer need this
target-agnostic code in getVScaleRange.
This patch implements the logic (for now, copied from
RISCVTargetInfo::getVScaleRange) so that we can compute the vscale_range
based off of the zvl*b extension, e.g. using an arch with zvl256b now
implies vscale_range(2,1024).
It's worth noting that we don't have to exactly copy the behaviour of
clang with regards to how it interacts with the
-mvscale-min/-mvscale-max flags, but changing it can be left to a future
patch.
This also adds a guard for +sve so that we only check for it on aarch64,
which was the behaviour prior to 898db1136e
Make sure that `-mvscale-max` and `-mvscale-min` are only available for
targets that are known to support vscale and scalable vectors.
Also fix capitalization of function variables.
If -nogpulib option is passed by the user, then the OpenMP device
runtime is not used and we should not emit globals to configure
debugging at compile-time for the device runtime.
Link to -nogpulib flag implementation for Clang:
https://reviews.llvm.org/D125314
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
We have other targets with scalable vectors (e.g.RISC-V), and there
doesn't seem to be any particular reason these options can't be used on
those targets.
Types of AMDGPU address space were defined not only in Clang-specific class
but also in LLVM header.
If we unify the AMD GPU address space enumeration, then we can reuse it in
Clang, Flang and LLVM.
Preliminary patch to change lowering/code generation to use
llvm::DataLayout information instead of generating "sizeof" GEP (see
https://github.com/llvm/llvm-project/issues/71507).
Fortran Semantic analysis needs to know about the target type size and
alignment to deal with common blocks, and intrinsics like
C_SIZEOF/TRANSFER. This information should be obtained from the
llvm::DataLayout so that it is consistent during the whole compilation
flow.
This change is changing flang-new and bbc drivers to:
1. Create the llvm::TargetMachine so that the data layout of the target
can be obtained before semantics.
2. Sharing bbc/flang-new set-up of the
SemanticConstext.targetCharateristics from the llvm::TargetMachine. For
now, the actual part that set-up the Fortran type size and alignment
from the llvm::DataLayout is left TODO so that this change is mostly an
NFC impacting the drivers.
3. Let the lowering bridge set-up the mlir::Module datalayout attributes
since it is doing it for the target attribute, and that allows the llvm
data layout information to be available during lowering.
For flang-new, the changes are code shuffling: the `llvm::TargetMachine`
instance is moved to `CompilerInvocation` class so that it can be used
to set-up the semantic contexts. `setMLIRDataLayout` is moved to
`flang/Optimizer/Support/DataLayout.h` (it will need to be used from
codegen pass for fir-opt target independent testing.)), and the code
setting-up semantics targetCharacteristics is moved to
`Tools/TargetSetup.h` so that it can be shared with bbc.
As a consequence, LLVM targets must be registered when running
semantics, and it is not possible to run semantics for a target that is
not registered with the -triple option (hence the power pc specific
modules can only be built if the PowerPC target is available.
Now that tbaa tags pass is enabled by default, I would like to remove
these flags. `-fno-alias-analysis` was originally intended to be useful
for debugging, but as it also disables tbaa tag generation in codegen,
it turned out to be too noisy.
@banach-space expressed that these flags felt too non-standard.
The tbaa tags pass can be toggled using `-mllvm
-disable-fir-alias-tags=0`
The `llvm::sys::fs::getMainExecutable(nullptr, nullptr)` is not able to
obtain the correct executable path on AIX without Argv0 due to the lack
of a current process on AIX's `proc` filesystem. This causes a build
failure on AIX as intrinsic module directory is missing.
---------
Co-authored-by: Mark Danial <mak.danial@ibm.com>
Enable by default for optimization levels higher than 0 (same behavior
as clang).
For simplicity, only forward the flag to the frontend driver when it
contradicts what is implied by the optimization level.
This was first landed in
https://github.com/llvm/llvm-project/pull/73111 but was later reverted
due to a performance regression. That regression was fixed by
https://github.com/llvm/llvm-project/pull/74065.
Moves the defintion of `SemanticsContext` within the Flang driver.
Rather than in `CompilerInvocation`, semantic context fits better within
`CompilerInstance` that encapsulates the objects that are required to
run the
frontend. `CompilerInvocation` is better suited for objects
encapsulating compiler configuration (e.g. set-up resulting from user
input or host set-up).
Information about code object version can be configured by the user for
AMD GPU target and it needs to be placed in LLVM IR generated by Flang.
Information about code object version in MLIR generated by the parser
can be reused by other tools. There is no need to specify extra flags if
we want to invoke MLIR tools (like fir-opt) separately.
Changes in comparison to a8ac93:
* added information about required targets for test
flang/test/Driver/driver-help.f90
Information about code object version can be configured by the user for
AMD GPU target and it needs to be placed in LLVM IR generated by Flang.
Information about code object version in MLIR generated by the parser
can be reused by other tools. There is no need to specify extra flags if
we want to invoke MLIR tools (like fir-opt) separately.
Enable by default for optimization levels higher than 0 (same behavior
as clang).
For simplicity, only forward the flag to the frontend driver when it
contradicts what is implied by the optimization level.
Since https://github.com/llvm/llvm-project/pull/72903 there are now no
known performance regressions.
This patch adds a --dependent-lib option to flang -fc1 on Windows to
embed library link options into the object file. This is needed to
properly select the Windows CRT to link against.
Before emitting a warning message, code should check that the usage in
question should be diagnosed by calling ShouldWarn(). A fair number of
sites in the code do not, and can emit portability warnings
unconditionally, which can confuse a user that hasn't asked for them
(-pedantic) and isn't terribly concerned about portability *to* other
compilers.
Add calls to ShouldWarn() or IsEnabled() around messages that need them,
and add -pedantic to tests that now require it to test their portability
messages, and add more expected message lines to those tests when
-pedantic causes other diagnostics to fire.
-fveclib= allows users to choose a vectorized libm so that loops
containing math functions are vectorized.
This is implemented as much as possible in the same way as in clang. The
driver test in veclib.f90 is copied from the clang test.
Patch 1/3 of the transition to use the HLFIR step by default in lowering
as described in
https://discourse.llvm.org/t/rfc-enabling-the-hlfir-lowering-by-default/72778/7
This option will allow to lower code without the HLFIR step during a
grace period as described in the RFC. It is not meant to be a long term
switch for flang.
The ultimate intention is to have this pass enabled by default whenever
we are optimizing for speed. But for now, just add the arguments so this
can be more easily tested.
PR: https://github.com/llvm/llvm-project/pull/68595
Add vscale range attirbute for the Scalable Vector Extension (SVE) if
provided on the command-line (options in a previous commit)
If no command-line option is provided, if the target-feature of SVE is
specified and the architecture is AArch64, it defualts to 128-2048. in
other words a vscale-min of 1, vscale-max of 16.
A pass is used to add the atribute to all functions. The vectorizer will
use this attribute to generate the SVE instruction to match the range
specified. The attribute is harmless if there is no vectorizable
operations in the function.
The CreateMLIRToLLVMPassPipeline function has quite a few arguments, all
of which has default values. Create a struct, with a constructor for the
default values, and pass that struct instead.
Re-arrange a few include files to make everything available.
No functional change intended.
Support for vector scale range arguments, for AArch64 scalable vector
extension (SVE) support.
Adds -msve-vector-bits to the flang frontend, and for flang fc1 the
options are -mvscale-min and -mvscale-max (optional). These match the
clang and clang cc1 options for the same purposes.
A further patch will actually USE these arguments.
This patch moves the group of OpenMP MLIR passes using after lowering of
Fortran to MLIR into a pipeline to be shared by `flang-new` and `bbc`.
Currently, the `bbc` tool does not produce the expected FIR for offloading-
enabled OpenMP codes due to not running these passes.
Unit tests exercising these passes are updated to check `bbc` output as well.
This will make it easy for callers to see issues with and fix up calls
to createTargetMachine after a future change to the params of
TargetMachine.
This matches other nearby enums.
For downstream users, this should be a fairly straightforward
replacement,
e.g. s/CodeGenOpt::Aggressive/CodeGenOptLevel::Aggressive
or s/CGFT_/CodeGenFileType::
This patch changes how common blocks are aggregated and named in
lowering in order to:
* fix one obvious issue where BIND(C) and non BIND(C) with the same
Fortran name were "merged"
* go further and deal with a derivative where the BIND(C) C name matches
the assembly name of a Fortran common block. This is a bit unspecified
IMHO, but gfortran, ifort, and nvfortran "merge" the common block
without complaints as a linker would have done. This required getting
rid of all the common block mangling early in FIR (\_QC) instead of
leaving that to the phase that emits LLVM from FIR because BIND(C)
common blocks did not have mangled names. Care has to be taken to deal
with the underscoring option of flang-new.
See added flang/test/Lower/HLFIR/common-block-bindc-conflicts.f90 for an
illustration.
For each R_Group diagnostic produced, this patch gives more
information about it by printing the absolute file path,
the line and column number the pass was applied to and finally
the remark option that was used.
Clang does the same with the exception of printing the relative
path rather than absolute path.
Depends on D159260. That patch adds support for backend passes
while this patch adds remark options to the backend test cases.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D159258
