Adds a range-based version of `std::move`, the version that moves a range, not the one that creates r-value references.
Reviewed By: dblaikie, gamesh411
Differential Revision: https://reviews.llvm.org/D83902
Summary:
All tuple values are passed directly to hash_combine. This is inspired by the implementation used for Swift:
4a1b4edbe1845f3829b9
Reviewers: gribozavr2
Reviewed By: gribozavr2
Subscribers: dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83887
This reverts commit 01bf8cdf5f.
Breaks the build:
llvm/include/llvm/ADT/FunctionExtras.h:223:7: error: explicit template argument list not allowed
223 | Callbacks<CallableT, CalledAs, EnableIfTrivial<CallableT>>;
Summary:
This technique should extend to rvalue-qualified etc, but I didn't add any.
I removed "volatile" from the future plans, which seems... speculative at best.
While here I moved the callbacks object out of the constructor into a
variable template, which I believe addresses the fixme there about unused
objects.
(I'm not a template guru, so it's always possible the old version was designed
for compile-time performance in a way I'm missing)
Reviewers: kadircet
Subscribers: dexonsmith, llvm-commits, chandlerc
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D82581
Context:
--------
There are places in LLVM where we need to pack typed fields into opaque values.
For instance, the `XXXInst` classes in `llvm/include/llvm/IR/Instructions.h` that extract informations from `Value::SubclassData` via `getSubclassDataFromInstruction()`.
The bit twiddling is done manually: this impairs readability and prevent consistent handling of out of range values (e.g. 435b458ad0/llvm/include/llvm/IR/Instructions.h (L564))
More importantly, the bit pattern is scattered throughout the implementation making it hard to pack additionnal fields or check for overlapping bits.
Design decisions:
-----------------
The Bitfield structs are to be declared together so it is clear which bits are used or not.
The code is designed with simplicity in mind, hence a few limitations:
- Storage is limited to a single integer,
- Enum values have to be `unsigned`,
- Storage type has to be `unsigned`,
- There are no automatic detection of overlapping fields (packed bitfield declaration should help though),
- The interface is C like so `storage` needs to be passed in everytime (code is simpler and lifetime considerations more obvious)
RFC: http://lists.llvm.org/pipermail/llvm-dev/2020-June/142196.html
Differential Revision: https://reviews.llvm.org/D81580
macOS goes to 11! This commit adds support for the new version number by ensuring
that existing version comparison routines, and the 'darwin' OS identifier
understands the new numbering scheme. It also adds a new utility method
'getCanonicalVersionForOS', which lets users translate some uses of
macOS 10.16 into macOS 11. This utility method will be used in upcoming
clang and swift commits.
Differential Revision: https://reviews.llvm.org/D82337
- Fixed a bug in hasNItems()
- Extend the STLExtras unit test to test hasSingleElement() and hasNItems() and friends.
Differential Revision: https://reviews.llvm.org/D82232
Summary:
When constructing an APSInt from a string, the constructor doesn't correctly
truncate the bit width of the result if the passed in string was "0" (or any
alternative way to express 0 like "-0" or "000"). Instead of 1 (which is the
smallest allowed bit width) it returns an APSInt with a bit width of 5.
The reason is that the constructor checks that it never truncates the result to
the invalid bit width of 0, so when it calculates that storing a "0" doesn't
require any bits it just keeps the original overestimated bit width (which
happens to be 5).
This patch just sets the bit width of the result to 1 if the required bit width
is 0.
Reviewers: arphaman, dexonsmith
Reviewed By: dexonsmith
Subscribers: hiraditya, dexonsmith, JDevlieghere, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81329
Summary:
Instead of iterating over all VarLoc IDs in removeEntryValue(), just
iterate over the interval reserved for entry value VarLocs. This changes
the iteration order, hence the test update -- otherwise this is NFC.
This appears to give an ~8.5x wall time speed-up for LiveDebugValues when
compiling sqlite3.c 3.30.1 with a Release clang (on my machine):
```
---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---
Before: 2.5402 ( 18.8%) 0.0050 ( 0.4%) 2.5452 ( 17.3%) 2.5452 ( 17.3%) Live DEBUG_VALUE analysis
After: 0.2364 ( 2.1%) 0.0034 ( 0.3%) 0.2399 ( 2.0%) 0.2398 ( 2.0%) Live DEBUG_VALUE analysis
```
The change in removeEntryValue() is the only one that appears to affect
wall time, but for consistency (and to resolve a pending TODO), I made
the analogous changes for iterating over SpillLocKind VarLocs.
Reviewers: nikic, aprantl, jmorse, djtodoro
Subscribers: hiraditya, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D80684
This lets it use sized deallocation and make more efficient alignment
decisions. Also adjust BumpPtrAllocator to always allocate at
alignof(std::max_align_t).
Summary: find_next_unset was returning size() instead of -1 in small-mode, when no unset bits are found.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D77985
BitVectors and SmallBitVectors with equal contents but different
capacities were getting different hashes.
Reviewed By: aganea
Differential Revision: https://reviews.llvm.org/D77038
Summary:
This revision adds two utilities currently present in MLIR to LLVM StringExtras:
* convertToSnakeFromCamelCase
Convert a string from a camel case naming scheme, to a snake case scheme
* convertToCamelFromSnakeCase
Convert a string from a snake case naming scheme, to a camel case scheme
Differential Revision: https://reviews.llvm.org/D78167
This class implements a switch-like dispatch statement for a value of 'T' using dyn_cast functionality. Each `Case<T>` takes a callable to be invoked if the root value isa<T>, the callable is invoked with the result of dyn_cast<T>() as a parameter.
Differential Revision: https://reviews.llvm.org/D78070
This revision moves several type_trait utilities from MLIR into LLVM. Namely, this revision adds:
is_detected - This matches the experimental std::is_detected
is_invocable - This matches the c++17 std::is_invocable
function_traits - A utility traits class for getting the argument and result types of a callable type
Differential Revision: https://reviews.llvm.org/D78059
It can be used to avoid passing the begin and end of a range.
This makes the code shorter and it is consistent with another
wrappers we already have.
Differential revision: https://reviews.llvm.org/D78016
Summary:
StringPool has many caveats and isn't used in the monorepo. I will
propose removing it as a patch separate from this refactoring patch.
Reviewers: rriddle
Subscribers: hiraditya, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D77976
This behaviour is in line with SmallBitVector and other vector-like
types.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D77027
This is the Waymarking algorithm implemented as an independent utility.
The utility is operating on a range of sequential elements.
First we "tag" the elements, by calling `fillWaymarks`.
Then we can "follow" the tags from every element inside the tagged
range, and reach the "head" (the first element), by calling
`followWaymarks`.
Differential Revision: https://reviews.llvm.org/D74415
Also add a test case to wasm-ld that asserts without this change.
Internally wasm-ld builds a StringMap of exported functions and it seems
like allowing empty string in the set is preferable to adding checks.
This assert looks like it was most likely just a historical accident.
It started life here purely to support InputLanguagesSet:
eeac27e38c
Then got extracted here:
e57a403338
Then got moved to AST here
5c48bae209
With the `InLang` paramater name still intact which suggested is
InputLanguagesSet origins.
Differential Revision: https://reviews.llvm.org/D74589
Without this some instances of copy construction would use the
converting constructor & lead to the destination function_ref referring
to the source function_ref instead of the underlying functor.
Discovered in feedback from 857bf5da35
Thanks to Johannes Doerfert, Arthur O'Dwyer, and Richard Smith for the
discussion and debugging.
This is the Waymarking algorithm implemented as an independent utility.
The utility is operating on a range of sequential elements.
First we "tag" the elements, by calling `fillWaymarks`.
Then we can "follow" the tags from every element inside the tagged
range, and reach the "head" (the first element), by calling
`followWaymarks`.
Differential Revision: https://reviews.llvm.org/D74415
MSVC insists on using the deleted move constructor instead of the copy
constructor:
http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/41203
C:\ps4-buildslave2\lld-x86_64-win7\llvm-project\llvm\unittests\ADT\CoalescingBitVectorTest.cpp(193):
error C2280: 'llvm::CoalescingBitVector<unsigned
int,16>::CoalescingBitVector(llvm::CoalescingBitVector<unsigned int,16>
&&)': attempting to reference a deleted function
advanceToLowerBound moves an iterator to the first bit set at, or after,
the given index. This can be faster than doing IntervalMap::find.
rdar://60046261
Differential Revision: https://reviews.llvm.org/D76466
Avoid making a heap allocation when constructing a CoalescingBitVector.
This reduces time spent in LiveDebugValues when compiling sqlite3 by
700ms (0.5% of the total User Time).
rdar://60046261
Differential Revision: https://reviews.llvm.org/D76465
Behavior of IEEEFloat::roundToIntegral is aligned with IEEE-754
operation roundToIntegralExact. In partucular this function now:
- returns opInvalid for signaling NaNs,
- returns opInexact if the result of rounding differs from argument.
Differential Revision: https://reviews.llvm.org/D75246
Jinsong Ji