This patch allows attaching user information, called "values" to each
identifier. The values are used to carry information along with variables and
are also used to determine if two variables are identical.
This patch is part of a series of patches to allow attaching user information
with variables in Presburger library.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D127347
This allows configuring LLVM unwinder separately from the C++ library
matching how we configure it in libcxx.
This also applies changes made to libunwind+libcxxabi+libcxx in D113253
to compiler-rt.
Differential Revision: https://reviews.llvm.org/D115674
The existing nm extractors can't dump the loader symbol table information we need to do the ABI checks for XCOFF, so provide an implementation using the system dump utility. We match the symbol name, whether it's defined, it's import/export status, and its storage mapping class.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D124165
This is an initial step of removing the SimpleSValBuilder abstraction. The SValBuilder alone should be enough.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D126127
This patch introduces a generic data-flow analysis framework to MLIR. The framework implements a fixed-point iteration algorithm and a dependency graph between lattice states and analysis. Lattice states and points are fully extensible to support highly-customizable analyses.
Reviewed By: phisiart, rriddle
Differential Revision: https://reviews.llvm.org/D126751
The combine step for shufflevector will sometimes replace undef in the mask
with a defined value. This can cause an infinite loop in some cases as another
combine will then put the undef back in the mask.
This patch fixes the issue so that undefs are not replaced when doing a combine.
Reviewed By: ZarkoCA, amyk, quinnp, saghir
Differential Revision: https://reviews.llvm.org/D127439
Also complete the set by adding a variant of depthwise 1d convolution
with the multiplier != 1.
Differential Revision: https://reviews.llvm.org/D127687
This redoes D103040 in a way that `AlwaysIncludeTypeForTemplateArgument = false`
policy is honored for printing template specialization types.
This can be seen for example when printing a canonicalized
dependent TemplateSpecializationType which has integral arguments.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: v.g.vassilev
Differential Revision: https://reviews.llvm.org/D126620
Introduce a transform dialect op that allows one to attempt different
transformation sequences on the same piece of payload IR until one of them
succeeds. This op fundamentally expands the scope of possibilities in the
transform dialect that, until now, could only propagate transformation failure,
at least using in-tree operations. This requires a more detailed specification
of the execution model for the transform dialect that now indicates how failure
is handled and propagated.
Transformations described by transform operations now have tri-state results,
with some errors being fundamentally irrecoverable (e.g., generating malformed
IR) and some others being recoverable by containing ops. Existing transform ops
directly implementing the `apply` interface method are updated to produce this
directly. Transform ops with the `TransformEachTransformOpTrait` are currently
considered to produce only irrecoverable failures and will be updated
separately.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D127724
Adds option to print the contents of the Inline Advisor after each SCC Inliner pass
Reviewed By: mtrofin
Differential Revision: https://reviews.llvm.org/D127689
This is possibly somewhat subjective, but having an explicitly named flag to track the property required and code structure that more closely matches phase 1/2 of the dataflow seems much easier to read.
Differential Revision: https://reviews.llvm.org/D126893
We are planning on making LTO the default compilation mode for
offloading. In order to make sure it works we should run these tests on
the test suite. AMDGPU already uses the LTO compilation path for its
linking, but in LTO mode it also links the static library late.
Performing LTO requires the static library to be built, if we make the
change this will be a hard requirement and the old bitcode library will
go away. This means users will need to use either a two-step build or a
runtimes build for libomptarget.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D127512
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D127738
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
The error used to look like this:
ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o
Now it displays the name of the function that contains the undefined
reference as well:
ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o:(symbol _baz+0x4)
Differential Revision: https://reviews.llvm.org/D127696
The `llvm/test/CodeGen/Thumb/frame-chain.ll`, recently added by D125094,
currently fails when expensive checks are enabled due to a tMOVr
instruction that is only valid from V6 onwards.
The use of the invalid instruction is unrelated to the contents of the
original patch, and continues to be triggered by this test if its
CodeGen changes are reverted, so this patch updates the test to use V6-M
while the issue is not resolved.
The offloading packager doesn't have a normal offloading kind. This
would result in its output being sent to the executable name when in
save-temps mode. This would then get overwritten by the actual output.
This patch adds specific checks to make sure that it gets the correct
name.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D127673
Add test coverage showing how the costs of fadd reductions is
overestimated at the moment.
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D127682
This patch adds implementations for the fill/spill SME ACLE intrinsics:
@llvm.aarch64.sme.ldr
@llvm.aarch64.sme.str
Differential Revision: https://reviews.llvm.org/D127317
Lowering was crashing with "fatal internal error: node has not been analyzed"
if a PDT with initial component value was defined inside an internal
procedure. This is because the related expression cannot be analyzed
without the component values (which happens at the instatiation).
These expression do not need to be visited (the instantiations, if any
will be). Use the form of GetExpr that tolerates the parse tree expression
to not be analyzed into an evaluate::Expr when looking through the
symbols used in an internal procedure.
Note that the PDTs TODO will then fire (it happens after the PFT
analysis) as expected if the derived type is used.
Differential Revision: https://reviews.llvm.org/D127735
Currently the a AAPCS compliant frame record is not always created for
functions when it should. Although a consistent frame record might not
be required in some cases, there are still scenarios where applications
may want to make use of the call hierarchy made available trough it.
In order to enable the use of AAPCS compliant frame records whilst keep
backwards compatibility, this patch introduces a new command-line option
(`-mframe-chain=[none|aapcs|aapcs+leaf]`) for Aarch32 and Thumb backends.
The option allows users to explicitly select when to use it, and is also
useful to ensure the extra overhead introduced by the frame records is
only introduced when necessary, in particular for Thumb targets.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D125094
This change specializes the LLVM RTTI mechanism for SVals.
After this change, we can use the well-known `isa`, `cast`, `dyn_cast`.
Examples:
// SVal V = ...;
// Loc MyLoc = ...;
bool IsInteresting = isa<loc::MemRegionVal, loc::GotoLabel>(MyLoc);
auto MRV = cast<loc::MemRegionVal>(MyLoc);
Optional<loc::MemRegionVal> MaybeMRV = dyn_cast<loc::MemRegionVal>(V)
The current `SVal::getAs` and `castAs` member functions are redundant at
this point, but I believe that they are still handy.
The member function version is terse and reads left-to-right, which IMO
is a great plus. However, we should probably add a variadic `isa` member
function version to have the same casting API in both cases.
Thanks for the extensive TMP help @bzcheeseman!
Reviewed By: bzcheeseman
Differential Revision: https://reviews.llvm.org/D125709
GetValueInMiddleOfBlock uses result of GetValueAtEndOfBlockInternal if there is no value
defined for current basic block.
If there is already a value it tries (in this order):
to find single register coming from all predecessors
find existing phi node which matches our incoming registers
build new phi.
The compile time improvement is to use current available value if
it is defined out of current BB or it is a PHI register.
This is due to it can be used in the middle basic block.
Reviewed By: sameerds
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D126523
Groverkss