`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.
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
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.
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.
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.
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.
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::
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
Previously, R_Group options only reported middle-end passes.
This patch allows backend passes to be reported as well.
Depends on D158174. That patch adds backend support to R_Group
options.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D159260
Add a BackendRemarkConsumer class, responsible for handling diagnostics
received from LLVM. The diagnostics being information on middle and
backend passes used or not used.
Clang by default has all remarks ignored but manually sets the severity of
`R_Group` to visible(`clang::diag::clang::Severity::Remark`). This patch does
the same for Flang.
Depends on D157410. That patch adds the R family of options to
`FlangOption` and `FC1Option` in
`clang/include/clang/Driver/Options.td`
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D158174
This patch improves the implementation of a recent function filtering
workaround to address problems uncovered by D154247.
In particular, the problem was related to the removal of functions called from
within target regions. Since target regions have to remain until LLVM IR is
generated, removing these functions from MLIR results in undefined references
any time there are calls to them in a target region. This patch modifies the
MLIR function filtering pass to make these functions "external" rather than
removing them. This way, the processing and lowering of MLIR functions that
will eventually be discarded is still prevented, but no calls to undefined
functions remain either.
Additionally, the approach of just filtering host-only functions during device
compilation, and not filtering device-only functions during host compilation,
is maintained. This is because code generation for device-only functions is
required for host fallback to work.
Depends on D156988
Differential Revision: https://reviews.llvm.org/D155827
Add support for generating and saving the optimization record.
Optimization record lists the optimizations performed by LLVM.
This patch enables the flag in Flang. Clang handles this functionality
using the BackendConsumer which Flang doesn't have, hence, was
implemented in CodeGenAction::executeAction
FlangOption added to all variants of fsave-optimization-record in
clang/include/clang/Driver/Options.td . Clang handles it the
same way.
opt_record_file, opt_record_passes and opt_record_format flags
in Options.td were moved out of the group [CC1Option, NoDriverOption]
to allow flang -fc1 support.
The renderRemarksOptions and willEmitRemarks functions in
clang/lib/Driver/ToolChains/Flang.cpp follow same syntax as clang.
In flang/lib/Frontend/CompilerInvocation.cpp we update the field
OptRecordFile with the provided optimization file value. Clang
doesn't do this as it processes the Options.td, mapping the
OptRecordFile earlier on.
Reviewed By: awarzynski, tblah
Differential Revision: https://reviews.llvm.org/D155452
This pass will mark functions called from TargetOp's
and declare target functions as implicitly declare
target by adding the MLIR declare target attribute
directly to the function.
This pass executes after the initial lowering of Fortran's PFT
to MLIR (FIR/OMP+Arith etc.) and is one of a series of passes
that aim to clean up the MLIR for offloading (seperate passes
in different patches, one for early outlining, another for declare
target function filtering).
Reviewers: jsjodin, skatrak, kiaranchandramohan
Differential Revision: https://reviews.llvm.org/D154247
This patch adds support for selecting which functions are lowered to LLVM IR
from MLIR depending on declare target information and whether host or device
code is being generated.
The approach proposed by this patch is to perform the filtering in two stages:
- An MLIR transformation pass, which is added to the Flang translation flow
after the `OMPEarlyOutliningPass`. The functions that are kept are those
that match the OpenMP processor (host or device) the compiler invocation
is targeting, according to the presence of the `-fopenmp-is-target-device`
compiler option and declare target information. All functions contaning an
`omp.target` are also kept, regardless of the declare target information of
the function, due to the need for keeping target regions visible for both
host and device compilation.
- A filtering step during translation to LLVM IR, which is peformed for those
functions that were kept because of the presence of a target region inside.
If the targeted OpenMP processor does not match the declare target
information of the function, then it is removed from the LLVM IR after its
contents have been processed and translated. Since they should only contain
an omp.target operation which, in turn, should have been outlined into
another LLVM IR function, the wrapper can be deleted at that point.
Depends on D150328 and D150329.
Differential Revision: https://reviews.llvm.org/D147641
This patch implements an early outlining transform of omp.target operations in
flang. The pass is needed because optimizations may cross target op region
boundaries, but with the outlining the resulting functions only contain a
single omp.target op plus a func.return, so there should not be any opportunity
to optimize across region boundaries.
The patch also adds an interface to be able to store and retrieve the parent
function name of the original target operation. This is needed to be able to
create correct kernel function names when lowering to LLVM-IR.
Reviewed By: kiranchandramohan, domada
Differential Revision: https://reviews.llvm.org/D154879
Extend the SourceFile class to take account of #line directives
when computing source file positions for error messages.
Adjust the output of #line directives to -E output so that they
reflect any #line directives that were in the input.
Differential Revision: https://reviews.llvm.org/D153910
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 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
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
/data/llvm-project/mlir/examples/toy/Ch4/toyc.cpp:119:5: error: ignoring return value of function declared with 'nodiscard' attribute [-Werror,-Wunused-result]
applyPassManagerCLOptions(pm);
^~~~~~~~~~~~~~~~~~~~~~~~~ ~~
1 error generated.
/data/llvm-project/flang/lib/Frontend/FrontendActions.cpp:669:3: error: ignoring return value of function declared with 'nodiscard' attribute [-Werror,-Wunused-result]
mlir::applyPassManagerCLOptions(pm);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~
1 error generated.
Scope of changes:
1) Add attribute to OpenMP MLIR dialect which stores target cpu and
target features
2) Store target information in MLIR module
Differential Revision: https://reviews.llvm.org/D146612
Reviewed By: kiranchandramohan
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
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
Scope of changes:
1) Extract common code between Clang and Flang for parsing AMDGPU features
2) Add function which adds implicit target features for AMDGPU as Clang does
3) Add AMDGPU target as one of valid targets for Flang
Differential Revision: https://reviews.llvm.org/D145579
Reviewed By: yaxunl, awarzynski
This commit adds the OffloadModuleInterface to the OpenMP dialect,
which will implement future module attribute get/set's for offloading.
Currently it implements set and get's for the omp.is_device attribute,
which is promoted to a real attribute in this commit as well (primarily
to allow switch cases to work nicely with it for future work and to keep
consistency with future module attributes).
This interface is attached to mlir::ModuleOp's on registration of the
OpenMPDialect and should be accessible anywhere the OpenMP
dialect is registered and initialized.
Reviewers: kiranchandramohan, awarzynski
Differential Revision: https://reviews.llvm.org/D146850
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
Without this patch we were asserting with a generic message `Failed to
create Target`, but we already have a detailed error message stored in
the variable `error` after calling `lookupTarget()` but this error was not
getting used/printed.
With this patch we will emit a message with more details instead of a
stack dump with a generic message.
Differential Revision: https://reviews.llvm.org/D146333
Change-Id: I7ddee917cf921a2133ca3e6b35791b2142f770a2
