Simply use the new PM syntax instead of the deprecated legacy PM
syntax when specifying the opt pipeline in some regression tests.
Differential Revision: https://reviews.llvm.org/D114518
The UpdateTestChecks tool itself does not care about which pass
manager that is used in the opt invocation. So the lit tests that
are verifying the behavior of the UpdateTestChecks tool is updated
to use the new-PM syntax (-passes=) when specifying the pass pipeline
in the test cases that are used for verifying the UpdateTestChecks
tool.
Differential Revision: https://reviews.llvm.org/D114517
The legacy PM is deprecated, so update a bunch of lit tests running
opt to use the new PM syntax when specifying the pipeline.
In this patch focus has been put on test cases for ConstantMerge,
ConstraintElimination, CorrelatedValuePropagation, GlobalDCE,
GlobalOpt, SCCP, TailCallElim and PredicateInfo.
Differential Revision: https://reviews.llvm.org/D114516
VLENB is the length of a vector register in bytes. We use
<vscale x 64 bits> to represent one vector register. The dwarf offset is
VLENB * scalable_offset / 8.
For the mask vector, it occupies one vector register.
Differential Revision: https://reviews.llvm.org/D107432
This diff fixes broken build caused by D108550. Under GCC 5, auto lambdas that capture this require `this->` for member calls.
Reviewed By: bondhugula
Differential Revision: https://reviews.llvm.org/D114659
Add missing tests to improve associative containers code coverage:
- Tests for key_comp() and value_comp() observers
- Tests for std::map and std::multimap value_compare member class
Reviewed by: ldionne, rarutyun, #libc
Differential Revision: https://reviews.llvm.org/D113998
Larger blocks are more convenient for compressions.
Blocks are allocated with MmapNoReserveOrDie to save some memory.
Also it's 15% faster on StackDepotBenchmarkSuite
Depends on D114464.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D114488
RESHAPE() fails inappropriately at runtime if the source array
is larger than the result -- which is perfectly valid -- because
of an obviously reversed comparison of their numbers of elements
is activating the runtime asserts meant for the opposite case
(source smaller than result).
Differential Revision: https://reviews.llvm.org/D114474
Relative to the previous landing attempt, this makes
insertValueToMap() resilient against the value already being
present in the map -- previously I only checked this for the
createSimpleAffineAddRec() case, but the same issue can also
occur for the general createNodeForPHI(). In both cases, the
addrec may be constructed and added to the map in a recursive
query trying to create said addrec. In this case, this happens
due to the invalidation when the BE count is computed, which
ends up clearing out the symbolic name as well.
-----
This adds validation for consistency of ValueExprMap and
ExprValueMap, and fixes identified issues:
* Addrec construction directly wrote to ValueExprMap in a few places,
without updating ExprValueMap. Add a helper to ensures they stay
consistent. The adjustment in forgetSymbolicName() explicitly
drops the old value from the map, so that we don't rely on it
being overwritten.
* forgetMemoizedResultsImpl() was dropping the SCEV from
ExprValueMap, but not dropping the corresponding entries from
ValueExprMap.
Differential Revision: https://reviews.llvm.org/D113349
This allows --power10-stubs= and --[no-]power10-stubs to override each other
(they are position dependent in GNU ld).
Also improve --help messages and the manpage.
Note: GNU ld's default "auto" mode uses heuristics to decide whether Power10
instructions are used. Arguably it is a design mistake of R_PPC64_REL24_NOTOC
(acked by the relevant folks on a libc-alpha discussion). We don't implement
"auto", so the default --power10-stubs is the same as "yes".
We check whether the maximum index of dimensional identifier present
in the result expressions is less than dimCount (number of dimensional
identifiers) argument passed in the AffineMap::get() and the maximum index
of symbolic identifier present in the result expressions is less than
symbolCount (number of symbolic identifiers) argument passed in AffineMap::get().
Reviewed By: nicolasvasilache, bondhugula
Differential Revision: https://reviews.llvm.org/D114238
Initially we were passing wrong numSymbols argument while calling
AffineMap::get() for creaating affine map with linearized result
expressions. The main problems was the number of symbols of the newly
to be created map may be different from that of the source map, as
new symbolic identifiers may be introduced while creating strided layout
linearized expressions.
Reviewed By: nicolasvasilache, bondhugula
Differential Revision: https://reviews.llvm.org/D114240
The canonical term is "extract" (GNU ld documentation, Solaris's `-z *extract`
options). Avoid inventing a term and match --why-extract. (ld64 prefers "load"
but the word is overloaded too much)
Mostly MFC, except for --help messages and the header row in
--print-archive-stats output.
This changes the op to produce `AnyVectorOfAnyRank` following mostly the code for 1-D vectors.
Depends On D114598
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D114550
This changes the op to produce `AnyVectorOfAnyRank` and implements this by just
inserting the element (skipping the shuffle that we do for the 1-D case).
Depends On D114549
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D114598
Previously, when adding a constraint to a Simplex that is already marked
as having no solutions (marked empty), the Simplex would be marked empty again,
and a second UnmarkEmpty entry would be pushed to the undo log. When rolling
back, Simplex should be unmarked empty only after rolling back past the
creation of the first constraint that made it empty.
Reviewed By: Groverkss
Differential Revision: https://reviews.llvm.org/D114613
Previously, the pivot function would only update the non-redundant rows when
pivoting. This is incorrect because in some cases, when rolling back past a
`detectRedundant` call, the basis being used could be different from that which
was used at the time of returning from the `detectRedundant` call. Therefore,
it is important to update the redundant rows as well during pivots. This could
also be triggered by pivots that occur when testing successive constraints for
being redundant in `detectRedundant` after some initial constraints are marked redundant.
Reviewed By: Groverkss
Differential Revision: https://reviews.llvm.org/D114614
Renamed the option for llvm-cov and changed variable names to use more
inclusive terms. Also changed the binary for the test.
Reviewed By: alanphipps
Differential Revision: https://reviews.llvm.org/D112816
Instead of silently swallowing errors that happen during Lit configuration
(for example trying to obtain compiler macros but compiling fails), raise
an exception with some amount of helpful information.
This should avoid the possibility of silently configuring Lit in a bogus
way, and also provides more helpful information when things fail.
Note that this requires a bit more finesse around how we handle some
failing configuration checks that we would previously return None for.
Differential Revision: https://reviews.llvm.org/D114010
-Wformat-nonliteral was turned on in https://reviews.llvm.org/D112927,
however we forgot to apply some __format__ attributes in Linux specific
code paths, which led to warnings when building on Linux. This patch
addresses that oversight.
Differential Revision: https://reviews.llvm.org/D113876
This reverts commit fac3f20de5.
I found this has broken how we detect the last memory region in
GetMemoryRegions/"memory region" command.
When you're debugging an AArch64 system with pointer authentication,
the ABI plugin will remove the top bit from the end address of the last
user mapped area.
(lldb)
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
ABI plugin removes anything above the 48th bit (48 bit virtual addresses
by default on AArch64, leaving an address of 0.
(lldb)
[0x0000000000000000-0x0000000000400000) ---
You get back a mapping for 0 and get into an infinite loop.
When a symbol comes from the non self-contained header, we recursively uplift
the file we consider used to the first includer that has a header guard. We
need to do this while we still have FileIDs because every time a non
self-contained header is included, it gets a new FileID but is later
deduplicated by HeaderID and it's not possible to understand where it was
included from.
Based on D114370.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D114623
Compiler has an analysis for perfect diamond matching but it does not
support nodes with main/alternate opcodes. The problem is that the
scalars themselves are different and might not match directly with other
nodes, but operands and main/alternate opcodes might match and compiler
might reuse some previously emitted vector instructions. Need to include
this analysis in the cost model and actual vector instructions emission
process.
Differential Revision: https://reviews.llvm.org/D114101
std::invoke_result takes function object type and arguments separately
(unlike std::result_of) so, std::invoke_result_t<F()> usage is
incorrect.
On the other hand, we don't need std::invoke() semantics here at all. So
just simplifying the code without extra dependency and use trailing
return type as the fix.
Reviewed By: MikeDvorskiy
Differential Revision: https://reviews.llvm.org/D114624
Certain commands like 'memory write', 'register read' etc all use
the OptionGroupFormat options but the help usage text for those
options is not customized to those commands.
One such example is:
(lldb) help memory read
-s <byte-size> ( --size <byte-size> )
The size in bytes to use when displaying with the selected format.
(lldb) help memory write
-s <byte-size> ( --size <byte-size> )
The size in bytes to use when displaying with the selected format.
This patch allows such commands to overwrite the help text for the options
in the OptionGroupFormat group as needed and fixes help text of memory write.
llvm.org/pr49018.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D114448
Accum is guaranteed to be defined outside L (via Loop::isLoopInvariant
checks above). I think that should guarantee that the more powerful
ScalarEvolution::isLoopInvariant also determines that the value is loop
invariant.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D114634
There is special logic for InsertSliceOp to check if a memcpy is needed. This change extracts that piece of code and makes it a PostAnalysisStep.
The purpose of this change is to untangle `bufferize` from BufferizationAliasInfo. (Not fully there yet.)
Differential Revision: https://reviews.llvm.org/D114513
Bjorn Pettersson