mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-09-24 21:40:12 +01:00
b3be298f7f4be4daf9f3f8738ea65a87be537939
230
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Dana Jansens
|
3d5d62e1c7 |
Allow making sets and maps with move-only keys and/or values (#4982)
When the key or value is move-only, then the set or map will be as well. |
||
 Jon Ross-PerkinsandDana Jansens
|
467e510d40 |
Document abbreviation style things (#4996)
We had a long discussion of this, so trying to document what seems to be the conclusion... and also clean up the exceptions that I could find. --------- Co-authored-by: Dana Jansens <danakj@orodu.net> |
||
|
Jon Ross-Perkins
|
21252b5e94 |
Add missing trailing return types (#5006)
Noted CopyNameFromImportIR while glancing around (this one's interesting because it's NameId, not void nor auto), did a scan just for a few other cases. Not an exhaustive fix, and TBH assuming we'd prefer `auto ... -> auto` since equivalent Carbon syntax would probably be `fn ... -> auto` |
||
|
Jon Ross-Perkins
|
2ea2166cf8 |
Update pre-commit (#4995)
`pre-commit autoupdate --freeze && pre-commit run -a` |
||
|
Jon Ross-Perkins
|
44a5e371b2 |
Reduce clangd-displayed errors for def files (#4957)
When I open a .def file, there are often 4 errors: - The #error - The #define is not defined - Missing `;` - Identifier naming This PR is meant to disable all of these, since they can be distracting from fixable diagnostics. |
||
|
Jon Ross-Perkins
|
2fef1cb713 |
Switch to trailing returns in toolchain and related code. (#4919)
Also makes the style guide explicitly comment on void, but this was the intent IIRC because it matches Carbon's `-> ()` (and "always" versus "except for void", which we definitely went back and forth on). Includes adjusting function pointers, which I definitely forget this syntax works sometimes. Excludes utils/tree_sitter/src/scanner.c because it claims to be C, but really we should probably fix that to be cpp. |
||
 Calvin
|
dcfccd3187 |
Support references in ErrorOr (#4889)
### Context & Motivation The error handling utilities in `//base/error.h` are very useful for writing code with strong safety guarantees. While hardening the `Dump` debug utilities (from review in #4866), I encountered a rough edge with references and pointers. After a [brief Discord discussion in #contributing-help](https://discord.com/channels/655572317891461132/1052653651895779359/1334675462877610038), it was suggested that adding support for references to `ErrorOr` would be a good candidate to move forward. Using a reference type with the `ErrorOr` class (e.g. `ErrorOr<Node&>`) produces two errors: <ol> <li><strong><code>variant can not have a reference type as an alternative</code></strong> <ul><li>From private field: <code>std::variant<Error, T> val_;</code></li></ul> </li> <li><strong><code>'operator->' declared as a pointer to a reference</code></strong> <ul><li>From member function: <code>auto operator->() -> T*</code></li></ul> </li> </ol> ### Changes To support reference types, both errors are resolved: 1. `std::reference_wrapper` is conditionally used for storage when `T` is a reference type 2. type trait aliases like `using ValueT = std::remove_reference_t<T>` are used to produce compatible types for methods like `auto operator->() -> ValueT*` |
||
|
Jon Ross-Perkins
|
b06fcc97f6 |
Clean up a few details of lex yaml printing (#4845)
- Escape dumped token strings (what got me here) - Change the quoting from backticks to quotes - Also add a `FormatEscaped` helper function for this, updating other `.write_escaped` uses |
||
 Richard SmithandJon Ross-Perkins
|
58fba078ee |
Add a flag to make CHECK failures non-fatal for debugging. (#4835)
`toolchain/autoupdate_testdata.py --allow-check-fail` can now be used to perform an autoupdate even if some `CARBON_CHECK`s are failing. What this does will depend on how the toolchain behaves after the `CHECK` failure, and of course there's no guarantees there, but this can be useful if it's easier to debug the `CHECK` failure by looking at the produced SemIR. Internally, this uses `bazel build --config=non-fatal-checks`, which in turn specifies a `--per_file_copt` for `check_internal.cpp`. The intent here is that the rebuild required to enable or disable this mode is as small as reasonably possible. This mode is not compatible with `-c opt`, as it's important that check failure calls are `[[noreturn]]` in `-c opt` mode. --------- Co-authored-by: Jon Ross-Perkins <jperkins@google.com> |
||
|
Jon Ross-Perkins
|
1670baf180 |
Make binary operators non-member (#4838)
Came up on #4831, style: "For a type T whose values can be compared for equality, define a non-member operator== and document when two values of type T are considered equal." https://google.github.io/styleguide/cppguide.html#Operator_Overloading Note while we could put some of these out-of-line, it's helpful to keep them inside the braces: - For private member access - For templated cases so that we aren't duplicating templates - Very mild preference for keeping class's API documented within the braces |
||
 Jon Ross-PerkinsandGeoff Romer
|
4c4c4a4d2c |
Add RawStringOstream for slightly simpler streaming to strings (#4817)
This adds a RawStringOstream. Versus TestRawOstream, which is
consolidated over to RawStringOstream, it uses a string for storage
instead of a vector, mainly to support move-to-string semantics. Versus
llvm::raw_string_ostream, it owns the string and supports pwrite (which
is needed for driver and its fd_ostream compatibility requirement).
This converts most uses of llvm::raw_string_ostream, leaving behind a
few in InstNamer that explicitly cannot own the string, such as:
```
llvm::raw_string_ostream(name)
<< "_" << tree.tokens().GetColumnNumber(token);
```
I have this as its own library so that it can use CHECK.
Yes this doesn't save much code, but it's code we repeatedly write.
---------
Co-authored-by: Geoff Romer <gromer@google.com>
|
||
|
Geoff RomerandRichard Smith
|
13434f0e8a |
Model var as a pattern operator (#4720)
Co-authored-by: Richard Smith <richard@metafoo.co.uk> |
||
|
Jon Ross-PerkinsandRichard Smith
|
a3e66d6116 |
Fix short option error (#4796)
"unsigned char" prints as an integer, not a char --------- Co-authored-by: Richard Smith <richard@metafoo.co.uk> |
||
|
Jon Ross-Perkins
|
82a346730a |
Fix clang-tidy issues (#4786)
Both of these I noticed from testing #4785, but they occur at head. ``` (elided)/execroot/_main/common/raw_hashtable.h:532:40: error: do not use nested 'std::max' calls, use an initializer list instead [modernize-min-max-use-initializer-list,-warnings-as-errors] 532 | static constexpr ssize_t Alignment = std::max<ssize_t>( | ^ 533 | {alignof(MetadataGroup), alignof(StorageEntry<KeyT, ValueT>)}); | ~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | static_cast<long>(alignof(MetadataGroup)) static_cast<long>(alignof(StorageEntry<KeyT, ValueT>)) (elided)/execroot/_main/toolchain/install/busybox_info_test.cpp:259:8: error: unused local variable 'usr_prefix' of type 'std::filesystem::path' [bugprone-unused-local-non-trivial-variable,-warnings-as-errors] 259 | auto usr_prefix = MakeInstallTree(dir_ / "usr"); | ^ (elided)/execroot/_main/toolchain/install/busybox_info_test.cpp:260:8: error: unused local variable 'usr_local_prefix' of type 'std::filesystem::path' [bugprone-unused-local-non-trivial-variable,-warnings-as-errors] 260 | auto usr_local_prefix = MakeInstallTree(dir_ / "usr/local"); | ^ ``` The std::max diagnostic seems a little confused, but the initializer list seems like it can be dropped without any loss. The unused locals diagnostic is correct. Neither of these seem like they should be newer than my last clang-tidy pass, maybe I just missed them in other sweeps. |
||
  
|
624950c62c |
Store hash in the probed_indices array in common/raw_hashtable.h to avoid its recomputation. (#4726)
Store hash in probed_indices array to avoid its recomputation. Benchmarks on ARM (altra, aarch64). ``` name old CYCLES/op new CYCLES/op delta BM_MapInsertSeq<Map<int, int>>/1 119 ± 2% 119 ± 1% ~ (p=0.961 n=55+54) BM_MapInsertSeq<Map<int, int>>/2 133 ± 1% 134 ± 1% ~ (p=0.342 n=56+57) BM_MapInsertSeq<Map<int, int>>/3 150 ± 1% 150 ± 1% ~ (p=0.856 n=56+57) BM_MapInsertSeq<Map<int, int>>/4 167 ± 2% 167 ± 2% ~ (p=0.430 n=56+57) BM_MapInsertSeq<Map<int, int>>/8 234 ± 5% 234 ± 3% ~ (p=0.957 n=57+57) BM_MapInsertSeq<Map<int, int>>/16 368 ± 4% 368 ± 4% ~ (p=0.762 n=57+57) BM_MapInsertSeq<Map<int, int>>/32 650 ± 4% 650 ± 4% ~ (p=0.955 n=57+57) BM_MapInsertSeq<Map<int, int>>/64 1.93k ± 4% 1.98k ± 4% +2.35% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, int>>/256 9.68k ± 5% 9.85k ± 3% +1.74% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, int>>/4096 177k ± 3% 163k ± 2% -8.17% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, int>>/65536 3.99M ± 3% 3.87M ± 4% -3.12% (p=0.000 n=56+56) BM_MapInsertSeq<Map<int, int>>/1048576 90.5M ± 5% 91.3M ± 6% +0.87% (p=0.025 n=55+55) BM_MapInsertSeq<Map<int, int>>/16777216 2.77G ± 8% 2.74G ± 9% ~ (p=0.076 n=57+57) BM_MapInsertSeq<Map<int, int>>/56 1.05k ± 5% 1.05k ± 5% ~ (p=0.727 n=57+57) BM_MapInsertSeq<Map<int, int>>/224 6.29k ± 5% 6.37k ± 4% +1.32% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, int>>/3584 124k ± 4% 109k ± 3% -12.46% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, int>>/57344 2.67M ± 4% 2.50M ± 4% -6.40% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, int>>/917504 65.3M ± 6% 65.8M ± 6% +0.89% (p=0.050 n=55+56) BM_MapInsertSeq<Map<int, int>>/14680064 2.17G ±10% 2.14G ± 9% -1.55% (p=0.032 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/1 122 ± 1% 122 ± 1% ~ (p=0.415 n=56+56) BM_MapInsertSeq<Map<int*, int*>>/2 136 ± 1% 136 ± 1% ~ (p=0.861 n=56+57) BM_MapInsertSeq<Map<int*, int*>>/3 153 ± 1% 153 ± 1% ~ (p=0.607 n=56+57) BM_MapInsertSeq<Map<int*, int*>>/4 170 ± 2% 174 ± 3% +2.34% (p=0.001 n=56+57) BM_MapInsertSeq<Map<int*, int*>>/8 238 ± 4% 242 ± 3% +1.59% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/16 382 ± 4% 383 ± 4% ~ (p=0.977 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/32 701 ± 7% 682 ± 5% -2.69% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/64 2.13k ± 6% 2.09k ± 3% -1.89% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/256 10.3k ± 3% 10.2k ± 3% -0.94% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/4096 184k ± 2% 179k ± 2% -2.62% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/65536 3.63M ± 2% 3.68M ± 3% +1.22% (p=0.000 n=54+57) BM_MapInsertSeq<Map<int*, int*>>/1048576 129M ±10% 129M ±10% ~ (p=0.874 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/16777216 3.27G ±11% 3.24G ±10% ~ (p=0.451 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/56 1.18k ± 9% 1.10k ± 5% -6.52% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/224 6.76k ± 5% 6.59k ± 4% -2.55% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/3584 117k ± 2% 115k ± 3% -1.93% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/57344 2.22M ± 3% 2.24M ± 2% +0.87% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/917504 95.0M ± 8% 94.8M ± 9% ~ (p=0.894 n=55+57) BM_MapInsertSeq<Map<int*, int*>>/14680064 2.42G ±14% 2.40G ±13% ~ (p=0.852 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/1 124 ± 1% 124 ± 1% ~ (p=0.604 n=56+55) BM_MapInsertSeq<Map<int, llvm::StringRef>>/2 140 ± 1% 140 ± 1% ~ (p=0.181 n=56+56) BM_MapInsertSeq<Map<int, llvm::StringRef>>/3 158 ± 1% 158 ± 3% ~ (p=1.000 n=56+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/4 176 ± 2% 176 ± 3% ~ (p=0.125 n=56+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/8 247 ± 4% 247 ± 2% ~ (p=0.614 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/16 391 ± 3% 391 ± 2% ~ (p=0.993 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/32 690 ± 3% 691 ± 3% ~ (p=0.224 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/64 2.17k ± 3% 2.22k ± 3% +1.94% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/256 11.1k ± 3% 11.3k ± 3% +1.58% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/4096 204k ± 2% 193k ± 2% -5.65% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/65536 5.19M ± 3% 5.09M ± 3% -2.05% (p=0.000 n=56+56) BM_MapInsertSeq<Map<int, llvm::StringRef>>/1048576 124M ±10% 123M ± 6% ~ (p=0.626 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/16777216 3.30G ± 9% 3.25G ± 8% -1.39% (p=0.019 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/56 1.12k ± 3% 1.12k ± 3% ~ (p=0.482 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/224 7.04k ± 4% 7.14k ± 3% +1.36% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/3584 138k ± 2% 126k ± 2% -8.89% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/57344 3.48M ± 4% 3.34M ± 4% -3.93% (p=0.000 n=56+56) BM_MapInsertSeq<Map<int, llvm::StringRef>>/917504 84.4M ± 7% 84.9M ± 6% ~ (p=0.159 n=56+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/14680064 2.42G ± 9% 2.40G ±10% ~ (p=0.300 n=57+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/1 168 ± 0% 168 ± 0% ~ (p=0.555 n=56+55) BM_MapInsertSeq<Map<llvm::StringRef, int>>/2 208 ± 0% 208 ± 0% ~ (p=0.722 n=52+53) BM_MapInsertSeq<Map<llvm::StringRef, int>>/3 248 ± 0% 248 ± 0% ~ (p=0.248 n=53+54) BM_MapInsertSeq<Map<llvm::StringRef, int>>/4 288 ± 0% 288 ± 0% ~ (p=0.185 n=54+55) BM_MapInsertSeq<Map<llvm::StringRef, int>>/8 457 ± 0% 457 ± 0% ~ (p=0.665 n=53+53) BM_MapInsertSeq<Map<llvm::StringRef, int>>/16 867 ± 1% 867 ± 1% ~ (p=0.174 n=47+52) BM_MapInsertSeq<Map<llvm::StringRef, int>>/32 1.61k ± 3% 1.62k ± 4% ~ (p=0.402 n=57+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/64 4.96k ± 9% 4.89k ± 5% -1.37% (p=0.046 n=57+54) BM_MapInsertSeq<Map<llvm::StringRef, int>>/256 26.9k ± 8% 26.5k ± 8% -1.51% (p=0.004 n=56+55) BM_MapInsertSeq<Map<llvm::StringRef, int>>/4096 600k ± 3% 588k ± 2% -2.07% (p=0.000 n=57+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/65536 13.9M ± 3% 13.5M ± 2% -2.99% (p=0.000 n=55+56) BM_MapInsertSeq<Map<llvm::StringRef, int>>/1048576 407M ± 7% 393M ± 5% -3.27% (p=0.000 n=56+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/16777216 10.2G ± 8% 9.9G ± 5% -3.50% (p=0.000 n=57+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/56 2.81k ± 5% 2.81k ± 4% ~ (p=0.809 n=56+56) BM_MapInsertSeq<Map<llvm::StringRef, int>>/224 17.9k ± 6% 17.6k ± 5% -1.20% (p=0.035 n=57+52) BM_MapInsertSeq<Map<llvm::StringRef, int>>/3584 374k ± 3% 367k ± 3% -1.80% (p=0.000 n=57+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/57344 8.64M ± 3% 8.53M ± 2% -1.29% (p=0.000 n=55+55) BM_MapInsertSeq<Map<llvm::StringRef, int>>/917504 247M ± 6% 244M ± 5% -1.19% (p=0.021 n=56+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/14680064 6.81G ± 8% 6.64G ± 6% -2.46% (p=0.000 n=57+57) ``` Benchmarks on x86 ``` name old cpu/op new cpu/op delta BM_MapInsertSeq<Map<int, int>>/1 32.9ns ± 3% 32.6ns ± 3% -0.84% (p=0.027 n=54+51) BM_MapInsertSeq<Map<int, int>>/2 35.9ns ± 3% 35.7ns ± 4% ~ (p=0.123 n=54+54) BM_MapInsertSeq<Map<int, int>>/3 39.7ns ± 3% 47.4ns ± 4% +19.40% (p=0.000 n=55+56) BM_MapInsertSeq<Map<int, int>>/4 52.7ns ± 3% 52.1ns ± 4% -1.22% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, int>>/8 78.1ns ± 3% 78.3ns ± 3% ~ (p=0.141 n=50+57) BM_MapInsertSeq<Map<int, int>>/16 135ns ± 3% 135ns ± 4% ~ (p=0.936 n=53+57) BM_MapInsertSeq<Map<int, int>>/32 249ns ± 3% 241ns ± 3% -3.28% (p=0.000 n=55+57) BM_MapInsertSeq<Map<int, int>>/64 631ns ± 3% 618ns ± 3% -2.21% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, int>>/256 2.62µs ± 3% 2.36µs ± 4% -10.02% (p=0.000 n=52+53) BM_MapInsertSeq<Map<int, int>>/4096 39.2µs ± 3% 37.9µs ± 4% -3.40% (p=0.000 n=57+56) BM_MapInsertSeq<Map<int, int>>/65536 972µs ± 3% 955µs ± 3% -1.76% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, int>>/1048576 16.2ms ± 4% 16.3ms ± 5% ~ (p=0.231 n=52+54) BM_MapInsertSeq<Map<int, int>>/16777216 651ms ± 3% 648ms ± 2% -0.42% (p=0.048 n=57+56) BM_MapInsertSeq<Map<int, int>>/56 418ns ± 3% 401ns ± 3% -4.10% (p=0.000 n=54+57) BM_MapInsertSeq<Map<int, int>>/224 1.79µs ± 3% 1.61µs ± 3% -10.20% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, int>>/3584 26.0µs ± 3% 24.9µs ± 4% -4.13% (p=0.000 n=57+56) BM_MapInsertSeq<Map<int, int>>/57344 560µs ± 3% 549µs ± 3% -2.11% (p=0.000 n=56+57) BM_MapInsertSeq<Map<int, int>>/917504 10.4ms ± 3% 10.4ms ± 3% ~ (p=0.805 n=56+56) BM_MapInsertSeq<Map<int, int>>/14680064 422ms ± 2% 421ms ± 3% ~ (p=0.269 n=57+56) BM_MapInsertSeq<Map<int*, int*>>/1 33.7ns ± 3% 33.7ns ± 3% ~ (p=0.620 n=55+55) BM_MapInsertSeq<Map<int*, int*>>/2 36.7ns ± 3% 36.5ns ± 3% ~ (p=0.160 n=55+56) BM_MapInsertSeq<Map<int*, int*>>/3 41.1ns ± 2% 41.0ns ± 4% ~ (p=0.284 n=54+56) BM_MapInsertSeq<Map<int*, int*>>/4 45.0ns ± 3% 53.9ns ± 4% +19.70% (p=0.000 n=57+56) BM_MapInsertSeq<Map<int*, int*>>/8 77.1ns ± 3% 80.9ns ± 4% +4.98% (p=0.000 n=55+57) BM_MapInsertSeq<Map<int*, int*>>/16 130ns ± 3% 136ns ± 4% +4.42% (p=0.000 n=56+57) BM_MapInsertSeq<Map<int*, int*>>/32 244ns ± 3% 246ns ± 4% +0.95% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/64 620ns ± 3% 674ns ± 3% +8.83% (p=0.000 n=55+57) BM_MapInsertSeq<Map<int*, int*>>/256 2.93µs ± 3% 2.88µs ± 3% -1.73% (p=0.000 n=56+56) BM_MapInsertSeq<Map<int*, int*>>/4096 54.0µs ± 3% 50.8µs ± 4% -6.01% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/65536 1.18ms ± 2% 1.17ms ± 4% ~ (p=0.083 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/1048576 28.9ms ± 4% 29.1ms ± 5% +0.91% (p=0.007 n=55+56) BM_MapInsertSeq<Map<int*, int*>>/16777216 914ms ± 2% 919ms ± 3% +0.56% (p=0.015 n=56+57) BM_MapInsertSeq<Map<int*, int*>>/56 404ns ± 3% 427ns ± 4% +5.60% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/224 1.88µs ± 3% 1.87µs ± 4% -0.68% (p=0.013 n=55+53) BM_MapInsertSeq<Map<int*, int*>>/3584 34.2µs ± 3% 32.9µs ± 4% -4.02% (p=0.000 n=56+57) BM_MapInsertSeq<Map<int*, int*>>/57344 768µs ± 3% 756µs ± 3% -1.53% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int*, int*>>/917504 16.4ms ± 5% 16.5ms ± 7% ~ (p=0.303 n=56+57) BM_MapInsertSeq<Map<int*, int*>>/14680064 607ms ± 2% 613ms ± 3% +0.92% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/1 34.1ns ± 3% 34.2ns ± 4% ~ (p=0.288 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/2 37.4ns ± 3% 37.5ns ± 3% ~ (p=0.316 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/3 41.8ns ± 4% 49.1ns ± 3% +17.45% (p=0.000 n=57+56) BM_MapInsertSeq<Map<int, llvm::StringRef>>/4 54.6ns ± 3% 53.9ns ± 5% -1.35% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/8 81.4ns ± 3% 81.4ns ± 4% ~ (p=0.956 n=56+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/16 139ns ± 3% 139ns ± 3% ~ (p=0.754 n=57+56) BM_MapInsertSeq<Map<int, llvm::StringRef>>/32 256ns ± 3% 250ns ± 4% -2.32% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/64 705ns ± 4% 687ns ± 3% -2.56% (p=0.000 n=53+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/256 2.95µs ± 5% 3.05µs ± 3% +3.42% (p=0.000 n=52+55) BM_MapInsertSeq<Map<int, llvm::StringRef>>/4096 49.6µs ± 3% 50.8µs ± 4% +2.44% (p=0.000 n=55+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/65536 1.39ms ± 3% 1.40ms ± 3% +0.65% (p=0.004 n=57+56) BM_MapInsertSeq<Map<int, llvm::StringRef>>/1048576 37.7ms ± 4% 38.1ms ± 4% +1.07% (p=0.001 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/16777216 1.20s ± 3% 1.20s ± 3% +0.50% (p=0.040 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/56 432ns ± 3% 414ns ± 3% -3.99% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/224 1.92µs ± 4% 1.89µs ± 4% -1.48% (p=0.000 n=52+55) BM_MapInsertSeq<Map<int, llvm::StringRef>>/3584 31.5µs ± 4% 32.1µs ± 4% +1.89% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/57344 757µs ± 3% 748µs ± 3% -1.28% (p=0.000 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/917504 21.9ms ± 4% 22.1ms ± 5% ~ (p=0.096 n=57+57) BM_MapInsertSeq<Map<int, llvm::StringRef>>/14680064 735ms ± 3% 737ms ± 3% ~ (p=0.208 n=57+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/1 41.5ns ± 3% 41.4ns ± 4% ~ (p=0.790 n=54+56) BM_MapInsertSeq<Map<llvm::StringRef, int>>/2 50.6ns ± 4% 50.6ns ± 5% ~ (p=0.684 n=53+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/3 59.7ns ± 4% 59.4ns ± 4% ~ (p=0.277 n=55+53) BM_MapInsertSeq<Map<llvm::StringRef, int>>/4 68.5ns ± 5% 68.2ns ± 5% ~ (p=0.623 n=54+55) BM_MapInsertSeq<Map<llvm::StringRef, int>>/8 107ns ± 5% 107ns ± 9% ~ (p=0.359 n=54+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/16 200ns ± 6% 200ns ± 6% ~ (p=0.772 n=56+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/32 373ns ± 8% 371ns ± 7% ~ (p=0.541 n=57+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/64 1.11µs ± 9% 1.09µs ± 8% -2.09% (p=0.003 n=56+56) BM_MapInsertSeq<Map<llvm::StringRef, int>>/256 5.61µs ± 5% 5.48µs ± 7% -2.42% (p=0.000 n=54+56) BM_MapInsertSeq<Map<llvm::StringRef, int>>/4096 153µs ± 4% 147µs ± 6% -3.80% (p=0.000 n=54+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/65536 3.24ms ± 3% 3.10ms ± 3% -4.19% (p=0.000 n=57+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/1048576 100ms ± 2% 98ms ± 3% -1.97% (p=0.000 n=56+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/16777216 2.45s ± 2% 2.40s ± 3% -2.09% (p=0.000 n=57+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/56 637ns ± 8% 630ns ± 8% ~ (p=0.101 n=56+56) BM_MapInsertSeq<Map<llvm::StringRef, int>>/224 3.77µs ± 6% 3.68µs ± 6% -2.42% (p=0.000 n=56+56) BM_MapInsertSeq<Map<llvm::StringRef, int>>/3584 92.1µs ± 7% 88.4µs ± 6% -4.04% (p=0.000 n=57+56) BM_MapInsertSeq<Map<llvm::StringRef, int>>/57344 1.99ms ± 4% 1.92ms ± 3% -3.47% (p=0.000 n=57+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/917504 62.1ms ± 4% 60.9ms ± 3% -1.93% (p=0.000 n=57+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/14680064 1.53s ± 3% 1.50s ± 3% -1.85% (p=0.000 n=57+57) ``` --------- Co-authored-by: Chandler Carruth <chandlerc@gmail.com> Co-authored-by: Carbon Infra Bot <carbon-external-infra@google.com> |
||
|
Vitaly Goldshteyn
|
384e1cbb92 |
Update Read*To* to improve operation dependency graph. (#4746)
Benchmarks for StringRef key seem slightly positive. ``` name old CYCLES/op new CYCLES/op delta BM_MapContainsHit<Map<llvm::StringRef, int>>/1/256 24.2 ± 0% 23.9 ± 0% -1.14% (p=0.000 n=54+55) BM_MapContainsHit<Map<llvm::StringRef, int>>/2/256 24.2 ± 0% 23.9 ± 0% -1.15% (p=0.000 n=53+54) BM_MapContainsHit<Map<llvm::StringRef, int>>/3/256 24.2 ± 0% 23.9 ± 0% -1.15% (p=0.000 n=53+54) BM_MapContainsHit<Map<llvm::StringRef, int>>/4/256 24.2 ± 0% 23.9 ± 0% -1.14% (p=0.000 n=56+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/8/256 25.4 ± 3% 26.3 ± 4% +3.61% (p=0.000 n=57+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/16/256 29.1 ± 2% 29.0 ± 2% -0.28% (p=0.030 n=56+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/32/256 29.2 ± 2% 29.0 ± 1% -0.59% (p=0.000 n=57+55) BM_MapContainsHit<Map<llvm::StringRef, int>>/64/256 30.1 ± 2% 30.0 ± 2% -0.43% (p=0.045 n=57+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/256/256 30.5 ± 1% 30.3 ± 1% -0.56% (p=0.000 n=56+56) BM_MapContainsHit<Map<llvm::StringRef, int>>/256/64 29.2 ± 1% 29.2 ± 2% ~ (p=0.513 n=55+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/256/128 29.6 ± 1% 29.5 ± 1% -0.34% (p=0.002 n=55+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/4096/256 32.0 ± 2% 31.9 ± 2% ~ (p=0.082 n=55+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/4096/1024 37.8 ± 2% 37.8 ± 1% ~ (p=0.751 n=57+55) BM_MapContainsHit<Map<llvm::StringRef, int>>/4096/2048 45.3 ± 2% 45.5 ± 2% +0.46% (p=0.001 n=57+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/65536/256 34.3 ± 2% 34.2 ± 2% -0.46% (p=0.000 n=57+56) BM_MapContainsHit<Map<llvm::StringRef, int>>/65536/16384 72.4 ± 3% 72.3 ± 2% ~ (p=0.458 n=54+50) BM_MapContainsHit<Map<llvm::StringRef, int>>/65536/32768 77.7 ± 3% 77.6 ± 3% ~ (p=0.774 n=56+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/1048576/256 34.9 ± 1% 34.8 ± 2% ~ (p=0.051 n=56+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/1048576/262144 115 ± 5% 115 ± 5% ~ (p=0.660 n=57+55) BM_MapContainsHit<Map<llvm::StringRef, int>>/1048576/524288 145 ± 4% 145 ± 5% ~ (p=0.917 n=57+55) BM_MapContainsHit<Map<llvm::StringRef, int>>/16777216/256 36.5 ± 2% 36.5 ± 2% ~ (p=0.250 n=57+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/16777216/4194304 288 ± 3% 287 ± 4% ~ (p=0.058 n=56+55) BM_MapContainsHit<Map<llvm::StringRef, int>>/16777216/8388608 303 ± 2% 302 ± 3% -0.47% (p=0.044 n=53+54) BM_MapContainsHit<Map<llvm::StringRef, int>>/56/256 29.1 ± 3% 29.0 ± 3% ~ (p=0.147 n=56+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/224/256 30.7 ± 2% 30.6 ± 2% ~ (p=0.140 n=56+55) BM_MapContainsHit<Map<llvm::StringRef, int>>/3584/256 31.4 ± 1% 31.3 ± 1% -0.42% (p=0.003 n=53+54) BM_MapContainsHit<Map<llvm::StringRef, int>>/3584/896 35.8 ± 2% 36.0 ± 2% +0.58% (p=0.000 n=57+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/3584/1792 43.5 ± 1% 43.6 ± 2% +0.21% (p=0.032 n=51+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/57344/256 34.3 ± 2% 34.1 ± 1% -0.43% (p=0.003 n=57+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/57344/14336 67.1 ± 2% 66.8 ± 2% ~ (p=0.057 n=57+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/57344/28672 72.8 ± 3% 72.5 ± 3% -0.45% (p=0.032 n=57+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/917504/256 34.7 ± 2% 34.6 ± 2% ~ (p=0.065 n=56+57) BM_MapContainsHit<Map<llvm::StringRef, int>>/917504/229376 104 ± 4% 104 ± 5% ~ (p=0.853 n=55+55) BM_MapContainsHit<Map<llvm::StringRef, int>>/917504/458752 114 ± 6% 114 ± 5% ~ (p=0.643 n=56+55) BM_MapContainsHit<Map<llvm::StringRef, int>>/14680064/256 36.4 ± 2% 36.2 ± 2% -0.58% (p=0.001 n=56+55) BM_MapContainsHit<Map<llvm::StringRef, int>>/14680064/3670016 271 ± 2% 271 ± 4% ~ (p=0.632 n=55+55) BM_MapContainsHit<Map<llvm::StringRef, int>>/14680064/7340032 285 ± 3% 285 ± 3% ~ (p=0.658 n=57+55) BM_MapContainsMiss<Map<llvm::StringRef, int>>/1 19.3 ± 1% 19.3 ± 2% ~ (p=0.201 n=55+57) BM_MapContainsMiss<Map<llvm::StringRef, int>>/2 19.4 ± 1% 19.3 ± 1% ~ (p=0.191 n=56+56) BM_MapContainsMiss<Map<llvm::StringRef, int>>/3 19.4 ± 1% 19.4 ± 2% ~ (p=0.422 n=55+56) BM_MapContainsMiss<Map<llvm::StringRef, int>>/4 19.4 ± 1% 19.4 ± 1% ~ (p=0.179 n=56+57) BM_MapContainsMiss<Map<llvm::StringRef, int>>/8 19.5 ± 2% 19.5 ± 1% ~ (p=0.148 n=54+57) BM_MapContainsMiss<Map<llvm::StringRef, int>>/16 19.7 ± 2% 19.6 ± 2% ~ (p=0.204 n=54+57) BM_MapContainsMiss<Map<llvm::StringRef, int>>/32 20.0 ± 3% 20.0 ± 3% ~ (p=0.917 n=56+54) BM_MapContainsMiss<Map<llvm::StringRef, int>>/64 19.8 ± 3% 19.8 ± 3% ~ (p=0.245 n=57+54) BM_MapContainsMiss<Map<llvm::StringRef, int>>/256 20.1 ± 3% 20.1 ± 3% ~ (p=0.307 n=57+56) BM_MapContainsMiss<Map<llvm::StringRef, int>>/4096 20.1 ± 3% 20.2 ± 2% ~ (p=0.070 n=57+56) BM_MapContainsMiss<Map<llvm::StringRef, int>>/65536 20.5 ± 3% 20.5 ± 3% ~ (p=0.174 n=56+57) BM_MapContainsMiss<Map<llvm::StringRef, int>>/1048576 20.9 ± 2% 20.8 ± 3% ~ (p=0.476 n=53+55) BM_MapContainsMiss<Map<llvm::StringRef, int>>/16777216 22.2 ± 4% 22.2 ± 3% ~ (p=0.807 n=57+57) BM_MapContainsMiss<Map<llvm::StringRef, int>>/56 24.9 ±28% 23.9 ±16% ~ (p=0.058 n=57+56) BM_MapContainsMiss<Map<llvm::StringRef, int>>/224 27.1 ±19% 26.6 ±19% ~ (p=0.122 n=57+56) BM_MapContainsMiss<Map<llvm::StringRef, int>>/3584 28.9 ±10% 28.7 ±10% ~ (p=0.405 n=56+57) BM_MapContainsMiss<Map<llvm::StringRef, int>>/57344 30.5 ± 7% 31.2 ± 7% +2.32% (p=0.000 n=57+56) BM_MapContainsMiss<Map<llvm::StringRef, int>>/917504 31.8 ± 7% 31.7 ± 7% ~ (p=0.713 n=57+56) BM_MapContainsMiss<Map<llvm::StringRef, int>>/14680064 33.4 ± 9% 33.5 ± 7% ~ (p=0.921 n=56+56) BM_MapLookupHit<Map<llvm::StringRef, int>>/1/256 49.3 ± 0% 48.2 ± 0% -2.17% (p=0.000 n=55+57) BM_MapLookupHit<Map<llvm::StringRef, int>>/2/256 49.3 ± 0% 48.2 ± 0% -2.17% (p=0.000 n=56+56) BM_MapLookupHit<Map<llvm::StringRef, int>>/3/256 49.3 ± 0% 48.2 ± 0% -2.17% (p=0.000 n=54+55) BM_MapLookupHit<Map<llvm::StringRef, int>>/4/256 49.3 ± 0% 48.2 ± 0% -2.17% (p=0.000 n=54+53) BM_MapLookupHit<Map<llvm::StringRef, int>>/8/256 49.0 ± 0% 48.0 ± 0% -2.02% (p=0.000 n=51+51) BM_MapLookupHit<Map<llvm::StringRef, int>>/16/256 51.8 ± 1% 51.3 ± 1% -0.89% (p=0.000 n=50+57) BM_MapLookupHit<Map<llvm::StringRef, int>>/32/256 51.8 ± 1% 51.3 ± 1% -1.07% (p=0.000 n=56+56) BM_MapLookupHit<Map<llvm::StringRef, int>>/64/256 52.4 ± 1% 51.8 ± 1% -1.12% (p=0.000 n=57+56) BM_MapLookupHit<Map<llvm::StringRef, int>>/256/256 54.6 ± 1% 54.1 ± 1% -0.94% (p=0.000 n=53+56) BM_MapLookupHit<Map<llvm::StringRef, int>>/256/64 51.9 ± 1% 51.4 ± 1% -0.95% (p=0.000 n=55+56) BM_MapLookupHit<Map<llvm::StringRef, int>>/256/128 52.5 ± 1% 52.0 ± 1% -1.07% (p=0.000 n=57+57) BM_MapLookupHit<Map<llvm::StringRef, int>>/4096/256 62.0 ± 3% 61.6 ± 3% -0.62% (p=0.002 n=55+57) BM_MapLookupHit<Map<llvm::StringRef, int>>/4096/1024 74.6 ± 1% 73.5 ± 1% -1.38% (p=0.000 n=56+56) BM_MapLookupHit<Map<llvm::StringRef, int>>/4096/2048 80.9 ± 1% 79.8 ± 1% -1.34% (p=0.000 n=57+56) BM_MapLookupHit<Map<llvm::StringRef, int>>/65536/256 72.0 ± 2% 71.4 ± 2% -0.77% (p=0.000 n=56+55) BM_MapLookupHit<Map<llvm::StringRef, int>>/65536/16384 145 ± 4% 145 ± 3% ~ (p=0.662 n=57+55) BM_MapLookupHit<Map<llvm::StringRef, int>>/65536/32768 155 ± 4% 156 ± 4% ~ (p=0.541 n=57+54) BM_MapLookupHit<Map<llvm::StringRef, int>>/1048576/256 73.1 ± 2% 72.5 ± 2% -0.73% (p=0.000 n=56+57) BM_MapLookupHit<Map<llvm::StringRef, int>>/1048576/262144 281 ± 7% 283 ± 5% ~ (p=0.284 n=57+49) BM_MapLookupHit<Map<llvm::StringRef, int>>/1048576/524288 342 ± 5% 342 ± 5% ~ (p=0.684 n=57+53) BM_MapLookupHit<Map<llvm::StringRef, int>>/16777216/256 77.5 ± 2% 76.9 ± 2% -0.74% (p=0.000 n=55+54) BM_MapLookupHit<Map<llvm::StringRef, int>>/16777216/4194304 750 ± 3% 749 ± 3% ~ (p=0.458 n=57+53) BM_MapLookupHit<Map<llvm::StringRef, int>>/16777216/8388608 802 ± 2% 801 ± 3% ~ (p=0.518 n=57+55) BM_MapLookupHit<Map<llvm::StringRef, int>>/56/256 51.9 ± 1% 51.3 ± 1% -1.10% (p=0.000 n=57+57) BM_MapLookupHit<Map<llvm::StringRef, int>>/224/256 54.0 ± 1% 53.5 ± 1% -1.01% (p=0.000 n=56+57) BM_MapLookupHit<Map<llvm::StringRef, int>>/3584/256 58.8 ± 2% 58.1 ± 2% -1.28% (p=0.000 n=56+57) BM_MapLookupHit<Map<llvm::StringRef, int>>/3584/896 69.7 ± 2% 68.7 ± 1% -1.35% (p=0.000 n=57+57) BM_MapLookupHit<Map<llvm::StringRef, int>>/3584/1792 77.1 ± 1% 76.0 ± 1% -1.45% (p=0.000 n=55+57) BM_MapLookupHit<Map<llvm::StringRef, int>>/57344/256 71.3 ± 2% 70.7 ± 3% -0.85% (p=0.000 n=55+57) BM_MapLookupHit<Map<llvm::StringRef, int>>/57344/14336 128 ± 3% 128 ± 3% ~ (p=0.556 n=57+56) BM_MapLookupHit<Map<llvm::StringRef, int>>/57344/28672 140 ± 4% 140 ± 3% ~ (p=0.735 n=57+51) BM_MapLookupHit<Map<llvm::StringRef, int>>/917504/256 72.8 ± 2% 72.3 ± 2% -0.76% (p=0.000 n=57+57) BM_MapLookupHit<Map<llvm::StringRef, int>>/917504/229376 242 ± 7% 243 ± 6% ~ (p=0.303 n=57+55) BM_MapLookupHit<Map<llvm::StringRef, int>>/917504/458752 264 ± 7% 264 ± 6% ~ (p=0.823 n=57+55) BM_MapLookupHit<Map<llvm::StringRef, int>>/14680064/256 76.4 ± 2% 75.8 ± 3% -0.78% (p=0.000 n=57+56) BM_MapLookupHit<Map<llvm::StringRef, int>>/14680064/3670016 696 ± 3% 698 ± 3% ~ (p=0.189 n=56+53) BM_MapLookupHit<Map<llvm::StringRef, int>>/14680064/7340032 749 ± 3% 750 ± 3% ~ (p=0.266 n=55+55) BM_MapUpdateHit<Map<llvm::StringRef, int>>/1/256 34.9 ± 0% 35.0 ± 0% +0.36% (p=0.000 n=56+50) BM_MapUpdateHit<Map<llvm::StringRef, int>>/2/256 34.9 ± 0% 35.0 ± 0% +0.35% (p=0.000 n=55+53) BM_MapUpdateHit<Map<llvm::StringRef, int>>/3/256 34.9 ± 0% 35.0 ± 0% +0.35% (p=0.000 n=55+55) BM_MapUpdateHit<Map<llvm::StringRef, int>>/4/256 34.9 ± 0% 35.0 ± 0% +0.36% (p=0.000 n=56+55) BM_MapUpdateHit<Map<llvm::StringRef, int>>/8/256 37.5 ± 3% 37.6 ± 2% ~ (p=0.081 n=57+56) BM_MapUpdateHit<Map<llvm::StringRef, int>>/16/256 39.4 ± 1% 39.5 ± 2% ~ (p=0.054 n=55+57) BM_MapUpdateHit<Map<llvm::StringRef, int>>/32/256 40.0 ± 3% 39.9 ± 4% ~ (p=0.449 n=56+55) BM_MapUpdateHit<Map<llvm::StringRef, int>>/64/256 40.0 ± 1% 40.1 ± 2% ~ (p=0.796 n=54+54) BM_MapUpdateHit<Map<llvm::StringRef, int>>/256/256 41.1 ± 2% 41.2 ± 2% ~ (p=0.061 n=53+50) BM_MapUpdateHit<Map<llvm::StringRef, int>>/256/64 39.6 ± 2% 39.6 ± 2% ~ (p=0.695 n=55+52) BM_MapUpdateHit<Map<llvm::StringRef, int>>/256/128 40.2 ± 2% 40.1 ± 2% ~ (p=0.507 n=53+49) BM_MapUpdateHit<Map<llvm::StringRef, int>>/4096/256 43.4 ± 2% 43.5 ± 2% ~ (p=0.300 n=53+56) BM_MapUpdateHit<Map<llvm::StringRef, int>>/4096/1024 50.9 ± 2% 51.8 ± 2% +1.79% (p=0.000 n=56+57) BM_MapUpdateHit<Map<llvm::StringRef, int>>/4096/2048 58.2 ± 1% 58.3 ± 1% ~ (p=0.072 n=57+57) BM_MapUpdateHit<Map<llvm::StringRef, int>>/65536/256 46.1 ± 1% 46.1 ± 2% ~ (p=0.197 n=54+53) BM_MapUpdateHit<Map<llvm::StringRef, int>>/65536/16384 88.1 ± 5% 88.9 ± 4% +0.90% (p=0.011 n=57+57) BM_MapUpdateHit<Map<llvm::StringRef, int>>/65536/32768 92.4 ± 3% 93.6 ± 3% +1.35% (p=0.000 n=57+57) BM_MapUpdateHit<Map<llvm::StringRef, int>>/1048576/256 46.6 ± 2% 46.7 ± 2% ~ (p=0.687 n=51+56) BM_MapUpdateHit<Map<llvm::StringRef, int>>/1048576/262144 144 ± 7% 145 ± 6% ~ (p=0.130 n=57+55) BM_MapUpdateHit<Map<llvm::StringRef, int>>/1048576/524288 181 ± 4% 182 ± 4% ~ (p=0.057 n=56+55) BM_MapUpdateHit<Map<llvm::StringRef, int>>/16777216/256 48.9 ± 2% 48.7 ± 2% -0.30% (p=0.042 n=56+53) BM_MapUpdateHit<Map<llvm::StringRef, int>>/16777216/4194304 351 ± 2% 350 ± 3% ~ (p=0.287 n=57+55) BM_MapUpdateHit<Map<llvm::StringRef, int>>/16777216/8388608 368 ± 3% 367 ± 3% ~ (p=0.710 n=57+55) BM_MapUpdateHit<Map<llvm::StringRef, int>>/56/256 39.7 ± 3% 39.6 ± 3% ~ (p=0.572 n=57+56) BM_MapUpdateHit<Map<llvm::StringRef, int>>/224/256 41.7 ± 2% 41.6 ± 3% ~ (p=0.233 n=55+56) BM_MapUpdateHit<Map<llvm::StringRef, int>>/3584/256 42.6 ± 2% 42.5 ± 2% ~ (p=0.309 n=54+55) BM_MapUpdateHit<Map<llvm::StringRef, int>>/3584/896 49.1 ± 1% 49.8 ± 1% +1.51% (p=0.000 n=57+56) BM_MapUpdateHit<Map<llvm::StringRef, int>>/3584/1792 57.0 ± 1% 57.1 ± 2% +0.30% (p=0.022 n=56+57) BM_MapUpdateHit<Map<llvm::StringRef, int>>/57344/256 46.1 ± 2% 46.0 ± 1% -0.28% (p=0.013 n=55+53) BM_MapUpdateHit<Map<llvm::StringRef, int>>/57344/14336 82.0 ± 2% 82.6 ± 2% +0.71% (p=0.000 n=57+56) BM_MapUpdateHit<Map<llvm::StringRef, int>>/57344/28672 88.7 ± 2% 89.8 ± 2% +1.22% (p=0.000 n=57+53) BM_MapUpdateHit<Map<llvm::StringRef, int>>/917504/256 46.5 ± 1% 46.5 ± 2% ~ (p=0.961 n=53+55) BM_MapUpdateHit<Map<llvm::StringRef, int>>/917504/229376 126 ± 5% 128 ± 5% +1.64% (p=0.000 n=57+54) BM_MapUpdateHit<Map<llvm::StringRef, int>>/917504/458752 140 ± 5% 141 ± 6% ~ (p=0.162 n=57+55) BM_MapUpdateHit<Map<llvm::StringRef, int>>/14680064/256 48.5 ± 2% 48.3 ± 2% ~ (p=0.094 n=55+54) BM_MapUpdateHit<Map<llvm::StringRef, int>>/14680064/3670016 328 ± 4% 328 ± 3% ~ (p=0.925 n=57+56) BM_MapUpdateHit<Map<llvm::StringRef, int>>/14680064/7340032 345 ± 3% 345 ± 3% ~ (p=0.489 n=57+55) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/1/256 76.0 ± 0% 75.9 ± 0% -0.03% (p=0.006 n=54+47) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/2/256 71.3 ± 1% 72.1 ± 5% ~ (p=0.750 n=52+54) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/3/256 70.9 ± 2% 70.7 ± 2% ~ (p=0.095 n=54+52) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/4/256 70.4 ± 2% 70.6 ± 3% ~ (p=0.458 n=47+56) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/8/256 75.0 ± 1% 74.2 ± 1% -1.16% (p=0.000 n=52+54) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/16/256 80.5 ± 3% 79.0 ± 3% -1.88% (p=0.000 n=51+53) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/32/256 83.2 ± 4% 82.3 ± 5% -1.01% (p=0.009 n=56+57) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/64/256 80.6 ± 3% 79.4 ± 4% -1.48% (p=0.000 n=52+54) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/256/256 83.6 ± 3% 82.6 ± 5% -1.23% (p=0.000 n=54+56) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/256/64 79.1 ± 6% 78.8 ± 8% ~ (p=0.359 n=55+56) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/256/128 81.1 ± 6% 80.3 ± 9% -1.04% (p=0.010 n=55+56) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/4096/256 85.5 ± 5% 84.1 ± 4% -1.61% (p=0.000 n=54+57) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/4096/1024 95.7 ± 3% 95.2 ± 2% -0.47% (p=0.033 n=56+55) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/4096/2048 101 ± 2% 101 ± 1% -0.68% (p=0.000 n=56+54) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/65536/256 90.5 ± 4% 88.1 ± 4% -2.57% (p=0.000 n=56+55) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/65536/16384 134 ± 3% 133 ± 2% -0.71% (p=0.002 n=57+57) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/65536/32768 142 ± 3% 141 ± 2% -0.90% (p=0.000 n=57+56) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/1048576/256 91.2 ± 3% 89.3 ± 4% -2.08% (p=0.000 n=56+55) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/1048576/262144 209 ± 5% 208 ± 5% ~ (p=0.170 n=57+54) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/1048576/524288 243 ± 5% 240 ± 5% -1.05% (p=0.020 n=57+55) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/16777216/256 94.3 ± 3% 92.5 ± 5% -1.91% (p=0.000 n=55+56) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/16777216/4194304 542 ± 3% 537 ± 4% -1.02% (p=0.000 n=57+56) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/16777216/8388608 566 ± 3% 561 ± 4% -1.01% (p=0.000 n=57+56) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/56/256 83.7 ±10% 81.3 ± 8% -2.84% (p=0.000 n=55+56) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/224/256 88.7 ± 8% 86.6 ± 9% -2.40% (p=0.001 n=57+55) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/3584/256 94.0 ± 5% 91.3 ± 4% -2.83% (p=0.000 n=56+56) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/3584/896 118 ± 4% 118 ± 5% ~ (p=0.930 n=57+55) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/3584/1792 143 ± 4% 141 ± 4% -1.10% (p=0.002 n=57+55) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/57344/256 102 ± 4% 100 ± 4% -2.31% (p=0.000 n=56+57) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/57344/14336 191 ± 2% 190 ± 1% -0.32% (p=0.024 n=57+55) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/57344/28672 197 ± 2% 197 ± 1% ~ (p=0.059 n=57+55) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/917504/256 103 ± 4% 101 ± 4% -1.99% (p=0.000 n=57+56) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/917504/229376 280 ± 3% 279 ± 3% ~ (p=0.145 n=57+52) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/917504/458752 298 ± 4% 296 ± 3% ~ (p=0.116 n=57+56) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/14680064/256 107 ± 4% 104 ± 4% -2.11% (p=0.000 n=55+56) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/14680064/3670016 613 ± 3% 612 ± 2% ~ (p=0.224 n=57+55) BM_MapEraseUpdateHit<Map<llvm::StringRef, int>>/14680064/7340032 637 ± 2% 635 ± 1% ~ (p=0.075 n=56+55) BM_MapInsertSeq<Map<llvm::StringRef, int>>/1 132 ± 0% 132 ± 0% -0.26% (p=0.000 n=47+41) BM_MapInsertSeq<Map<llvm::StringRef, int>>/2 160 ± 0% 161 ± 4% +0.57% (p=0.001 n=45+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/3 188 ± 2% 189 ± 3% ~ (p=0.327 n=54+54) BM_MapInsertSeq<Map<llvm::StringRef, int>>/4 217 ± 3% 218 ± 5% ~ (p=0.240 n=54+56) BM_MapInsertSeq<Map<llvm::StringRef, int>>/8 342 ± 5% 341 ± 4% ~ (p=0.282 n=53+54) BM_MapInsertSeq<Map<llvm::StringRef, int>>/16 640 ± 3% 648 ± 8% +1.26% (p=0.023 n=49+54) BM_MapInsertSeq<Map<llvm::StringRef, int>>/32 1.20k ± 8% 1.20k ± 8% ~ (p=0.423 n=53+54) BM_MapInsertSeq<Map<llvm::StringRef, int>>/64 3.57k ± 8% 3.55k ± 6% ~ (p=0.557 n=57+54) BM_MapInsertSeq<Map<llvm::StringRef, int>>/256 18.6k ± 5% 18.6k ± 6% ~ (p=0.799 n=57+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/4096 492k ± 4% 491k ± 3% ~ (p=0.378 n=56+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/65536 10.5M ± 2% 10.4M ± 1% ~ (p=0.143 n=57+48) BM_MapInsertSeq<Map<llvm::StringRef, int>>/1048576 323M ± 2% 322M ± 3% ~ (p=0.098 n=56+56) BM_MapInsertSeq<Map<ll::StringRef, int>>/16777216 7.07G ± 3% 7.05G ± 4% ~ (p=0.195 n=56+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/56 2.04k ± 8% 2.03k ± 7% ~ (p=0.124 n=52+55) BM_MapInsertSeq<Map<llvm::StringRef, int>>/224 12.0k ± 5% 12.0k ± 4% ~ (p=0.467 n=57+55) BM_MapInsertSeq<Map<llvm::StringRef, int>>/3584 294k ± 5% 292k ± 4% ~ (p=0.188 n=56+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/57344 6.40M ± 2% 6.39M ± 1% ~ (p=0.381 n=57+56) BM_MapInsertSeq<Map<llvm::StringRef, int>>/917504 199M ± 3% 199M ± 3% ~ (p=0.977 n=57+57) BM_MapInsertSeq<Map<llvm::StringRef, int>>/14680064 4.56G ± 3% 4.55G ± 3% ~ (p=0.129 n=55+56) ``` |
||
 ezbr
|
9d09061301 |
Avoid misaligned loads from StaticRandomData in the size [4, 8] hashing case. (#4743)
Avoid misaligned loads from StaticRandomData in the size [4, 8] hashing case. We can use aligned loads in this case for lower latency. We introduce the SampleAlignedRandomData function for this purpose. |
||
|
ezbr
|
afdf846636 |
Align StaticRandomData to cacheline size. (#4741)
Align StaticRandomData to cacheline size to ensure the whole array is on the same cacheline. |
||
 Chandler CarruthandDanila Kutenin
|
3ae968a74c |
Teach the SIMD metadata group match to defer masking (#4595)
When using a byte-encoding for matched group metadata we need to mask down to a single bit in each matching byte to make the iteration of a range of match indices work. In most cases, this mask can be folded into the overall match computation, but for Arm Neon, there is avoidable overhead from this. Instead, we can defer the mask until starting to iterate. Doing more than one iteration is relative rare so this doesn't accumulate much waste and makes common paths a bit faster. For the M1 this makes the SIMD match path about 2-4% faster. This isn't enough to catch the portable match code path on the M1 though. For some Neoverse cores the difference here is more significant (>10% improvement) and it makes the SIMD and scalar code paths have comparable latency. Still not clear which is better as the latency is comparable and beyond latency the factors are very hard to analyze -- port pressure on different parts of the CPU, etc. Leaving the selected code path as portable since that's so much better on the M1, and I'm hoping to avoid different code paths for different Arm CPUs for a while. --------- Co-authored-by: Danila Kutenin <danilak@google.com> |
||
|
Jon Ross-PerkinsandRichard Smith
|
3f9a06aee3 |
Look at flipping clang-tidy's misc-* to enable-by-default (#4699)
I was wondering, instead of treating `misc` differently and enabling specific checks, maybe we can flip that since we actually seem okay with most of the checks? The main check I'm enabling, with significant edits here, is `misc-no-recursion`. But maybe this is helpful to enable, even with the necessary NOLINTs, since we want to avoid recursion in the toolchain? This PR shows some example fixes in subst.cpp (which are more stylistic, since the code shouldn't actually have recursed due to its structure; I think we could remove the warning on TryResolveInst the same way). Some also just don't seem worth fixing, like those in tests files (I didn't see a way to exclude files in .clang-tidy, so instead I'm using NOLINTBEGIN). But I think we might actually want to fix inst_namer, and there's enough in convert that I didn't look closely. Also, I made some protected -> private style fixes based on `misc-non-private-member-variables-in-classes` (this is also how I noticed `class Real` versus `struct Real`). With node_stack, it looks like the `protected` wasn't even used. [Per style](https://google.github.io/styleguide/cppguide.html#Access_Control), data members should be private outside tests. But since we can't trivially exclude `protected` members in tests, I'm turning it off -- I don't view it as offering enough benefit on the whole. migrate_cpp issues are preexisting (I believe we just aren't monitoring it), but changes there make `bazel build --config=clang-tidy -k //...` work cleanly. --------- Co-authored-by: Richard Smith <richard@metafoo.co.uk> |
||
|
Jon Ross-Perkins
|
c832d523be |
Update files and clang-tidy config to pass with clang-tidy-20 (#4691)
Disables three new warnings because they lean more towards style conflicts than fixes. I've brought these up on #style. Other than that, mostly fixing basic issues, and things that clang-tidy-20 seems to fire where clang-tiday-16 didn't. One particular curious case is `llvm::StringLiteral::data()` uses, which are flagged as not strictly null-terminated; I'm switching to `const char*` in those spots which matches `llvm::formatv`'s format argument, but feels worse. I'm removing `run_clang_tidy.py` here because I'm observing it give fewer warnings than `bazel build --config=clang-tidy -k //toolchain/...`. The latter matches how we enforce in GitHub actions (and also caches results, and suppresses output for files that have no issues), so I'm dropping the bespoke script. |
||
|
Dana Jansens
|
c7ae2a7b18 |
Avoid printing enums as characters (#4676)
Given code like the following:
```
auto kind = ConversionTarget::Kind{0};
CARBON_CHECK(!loc_id.is_valid(), "hello {0} world", kind);
```
Currently we would print 'hello <the next line>', as the check string
would be treated as terminating at the '{0}', so it does not print the
rest of the string or a newline. This is because ConversionTarget::Kind
is an enum with underlying type `int8_t` which is a char, and
llvm::formatv does not look if the type is an enum and treat is
specially. So it prints it as a char rather than a number, which in this
case is a nul terminator.
With this change, the '{0}' value will be converted to a larger integer
before being passed through to llvm::formatv so that char-sized enums
will print as a number, and the result is that we will print 'hello 0
world\n' as the developer intended.
|
||
|
Jon Ross-PerkinsandDana Jansens
|
3ce0df67bb |
Add Dump functions to Check, Parse, and Lex (#4669)
- Provide `Check::Dump(context, arg)` and similar. - gdb and lldb should do contextual lookup, and `call Dump(*this, Lex::TokenIndex::Invalid)` has been tested with gdb. - Since this is only for debug, keeps the functions fully separated from code. - Uses alwayslink to ensure objects are correctly linked, even though there are no calls. - `-Wno-missing-prototypes` is needed when we don't have forward declarations. - Code is not linked in opt builds, using `#ifndef NDEBUG`. - This probably could be doing something in BUILD files with a `select()`, but the `#ifndef` seemed easier. This is based on #4620, but uses free functions instead of member functions. Co-authored-by: Dana Jansens <danakj@orodu.net> --------- Co-authored-by: danakj <danakj@orodu.net> |
||
|
Jon Ross-Perkins
|
61c0a8b676 |
Make more use of llvm STLExtras (#4668)
This is essentially the result of looking at `.begin()` uses. We also frequently do `std::shuffle`, but unfortunately STLExtras doesn't provide a wrapper for that. |
||
 Boaz Brickner
|
fe8b42148f |
Mark some //common, //toolchain/driver, //toolchain/install tests as small per 'Test execution time' warning (#4646)
These tests only take between 0.1s and 1.4s. |
||
|
Richard Smith
|
a45cb86bf7 |
Add a compile-time check that the condition of a CHECK is not constant. (#4628)
Inspired by #4624. |
||
|
Richard Smith
|
c571b0f13b | Don't print a comma in a two-item list. (#4596) | ||
|
Jon Ross-Perkins
|
5880954041 |
Refactor command line errors to mirror diagnostic style (#4568)
This changes to an `Error` return to let the driver do the "error: " prefix, except for one case with `help` that needs more work to change (I'm not planning on picking up that TODO). It also changes capitalization, backtick use, and a few minor punctuation things to try to better match the diagnostic style. This also adds `Error` matchers so that the changes to command line testing are clearer. |
||
|
Chandler Carruth
|
a2af7ad8f0 |
Improve hashtable prefetching (#4585)
I had removed most but not all of the hashtable prefetching during development because I wasn't confident in the benchmarking results. However, I never revisited this once the benchmarking infrastructure improved and there were solid and stable results. This factors the two interesting prefetch patterns I've seen for this style of hashtable into helpers that are always called, and provides macros that can be used during the build to configure exactly which prefetch strategies are enabled. Benchmarking these and gaining confidence is very frustrating -- even now with the improved infrastructure, the noise is much higher than I would like. But it seems clear that *some* prefetching is a significant win. It also seems like enabling both results in too much prefetch traffic. And the entry group prefetch appears to be significantly more effective, both for the most interesting of the microbenchmarks and maybe most importantly for our compilation benchmarks. There, AMD is helped substantially and M1 seems to be helped some (although harder to measure). AMD server benchmark numbers: ``` name old cpu/op new cpu/op delta BM_CompileAPIFileDenseDecls<Phase::Lex>/256 35.0µs ± 2% 34.2µs ± 2% -2.40% (p=0.000 n=20+19) BM_CompileAPIFileDenseDecls<Phase::Lex>/1024 156µs ± 2% 151µs ± 2% -3.18% (p=0.000 n=20+19) BM_CompileAPIFileDenseDecls<Phase::Lex>/4096 625µs ± 1% 605µs ± 1% -3.22% (p=0.000 n=19+18) BM_CompileAPIFileDenseDecls<Phase::Lex>/16384 2.79ms ± 1% 2.69ms ± 2% -3.67% (p=0.000 n=17+19) BM_CompileAPIFileDenseDecls<Phase::Lex>/65536 12.1ms ± 1% 11.6ms ± 1% -4.30% (p=0.000 n=17+18) BM_CompileAPIFileDenseDecls<Phase::Lex>/262144 56.6ms ± 1% 53.8ms ± 1% -5.00% (p=0.000 n=18+17) BM_CompileAPIFileDenseDecls<Phase::Parse>/256 61.1µs ± 2% 61.7µs ± 1% +0.87% (p=0.000 n=19+19) BM_CompileAPIFileDenseDecls<Phase::Parse>/1024 288µs ± 1% 290µs ± 1% +0.55% (p=0.004 n=20+20) BM_CompileAPIFileDenseDecls<Phase::Parse>/4096 1.16ms ± 1% 1.16ms ± 1% -0.54% (p=0.000 n=17+19) BM_CompileAPIFileDenseDecls<Phase::Parse>/16384 4.98ms ± 1% 4.91ms ± 1% -1.39% (p=0.000 n=20+19) BM_CompileAPIFileDenseDecls<Phase::Parse>/65536 20.9ms ± 1% 20.5ms ± 1% -1.86% (p=0.000 n=20+19) BM_CompileAPIFileDenseDecls<Phase::Parse>/262144 92.1ms ± 1% 90.2ms ± 1% -2.12% (p=0.000 n=18+20) BM_CompileAPIFileDenseDecls<Phase::Check>/256 1.16ms ± 2% 1.16ms ± 1% ~ (p=0.931 n=19+19) BM_CompileAPIFileDenseDecls<Phase::Check>/1024 2.17ms ± 2% 2.16ms ± 1% ~ (p=0.247 n=20+19) BM_CompileAPIFileDenseDecls<Phase::Check>/4096 6.07ms ± 1% 6.04ms ± 1% -0.48% (p=0.007 n=19+19) BM_CompileAPIFileDenseDecls<Phase::Check>/16384 22.4ms ± 1% 22.2ms ± 1% -0.99% (p=0.000 n=20+19) BM_CompileAPIFileDenseDecls<Phase::Check>/65536 93.3ms ± 1% 92.2ms ± 1% -1.23% (p=0.000 n=20+18) BM_CompileAPIFileDenseDecls<Phase::Check>/262144 400ms ± 1% 391ms ± 1% -2.15% (p=0.000 n=20+18) ``` |
||
|
Chandler Carruth
|
b08fefc896 |
Change the test timeouts for the benchmarks to moderate. (#4570)
After some poking, it would take a more significant change to restructure the string generation to take less time when run under ASan, and it's not worth it at the moment. For future reference, nearly half the time here is in building the global data structures of random string contents, not in the actual benchmark functions. If/when we want to improve this, we should switch to a growing pool of random strings similar to what `SourceGen` uses. That lets it not allocate the full size of data when just testing that the benchmark doesn't crash. I thought about having these benchmarks switch to use `SourceGen`, but I'd like to keep them stand-alone if easy, and there are some important differences that would have to be adapted around which wouldn't be trivial. I'd rather come back in with a better generation strategy than re-use the source code one here. |
||
|
Chandler Carruth
|
637539726d |
Switch to our custom benchmark main. (#4567)
I'm working on speeding up the benchmark tests and noticed they weren't using our main, seemed worth cleaning that up. |
||
|
Jon Ross-Perkins
|
493d766a97 |
Have sh_test directly invoke benchmarks (#4552)
These tests typically take 10-20s, but I'm seeing some timeouts [here](https://github.com/carbon-language/carbon-lang/actions/runs/11899548036/job/33158400417). This seemed particularly suspicious due to the _absence_ of output (copied below). That got me looking, and maybe the subprocessing tickles a cpu bottleneck, so proposing this approach to remove the exec. Even if this doesn't solve the flakiness, I think it's a simpler implementation. Note I believe this is intended to work. The `sh` rules rely on shebangs (as noted at https://bazel.build/reference/be/shell#sh_test), and are essentially just subprocessing to the input. Note this could've also had `args` on a `cc_test` rule, but I'd expect the same args to be passed to `run` where instead the benchmark behavior should be default (and I'm assuming you'd rather not have args there). Fundamentally this becomes a symlink: ``` bazel-bin/common/map_benchmark_test -> .../execroot/_main/bazel-out/k8-fastbuild/bin/common/map_benchmark ``` Copying snippet from timeout below: ``` ==================== Test output for //common:map_benchmark_test: /private/var/tmp/_bazel_runner/e591f63ed099023de1f206992dfce127/execroot/_main/bazel-out/darwin_arm64-fastbuild/testlogs/common/map_benchmark_test/test.log -- Test timed out at 2024-11-18 19:32:13 UTC -- INFO: From Testing //common:map_benchmark_test: ================================================================================ ``` |
||
|
Jon Ross-Perkins
|
d8ecc72d9d |
Update pre-commit config (#4549)
Skipping prettier because the relevant repo is archived and not working well. Issues being fixed are from codespell. |
||
|
Jon Ross-Perkins
|
be56ff87c6 |
Convert StructTypeField to a specific type. (#4492)
This converts `StructTypeField` from an instruction to a dedicated type, with its own store. This had originated from discussing how `.GetAs<SemIR::StructTypeField>` was more prevalent than for other instructions, but is probably more interesting for the storage savings (16 bytes StructTypeField + 4 byte LocId + 4 byte InstId -> 8 byte StructTypeField). Due to the different structure, these now have their own stack during construction, reducing (but not eliminating) `args_type_info_stack_` use-cases. The test changes of different InstIds is expected because structs and classes generate fewer instructions now. Other than that, results should remain the same. I'm generally trying to avoid unrelated cleanup here due to the PR size, though I did scrutinize the `VerifyOnFinish` calls, adding one and commenting others (putting them in member order because that's how I was checking what was verified and what wasn't). |
||
 David BlaikieandRichard Smith
|
dfed743de2 |
Add vtable pointers to class layout (#4407)
A small step to virtual functions - adding vtable pointers to the
layout, but not initializing or otherwise using them at this stage.
A few open design questions I'd love feedback on:
* Is this the right/good enough SemIR representation for now? This patch
adds a `is_dynamic` attribute to `SemIR::Class` and populates/flags it
based on the flag of the base class, or if any virtual function is
declared in the class (or, at least that's my intent). Some other
options include:
* Each `Class` could store a `ClassId` (or `TypeId`?) of the (possibly
indirect, possibly self) base class that is the first one that is
dynamic/has a vtable pointer
* Could make the property narrower, like `has vtable pointer` and have
it `true` only on the type that introduces the vtable - then derived
classes would have to walk their base classes to check if they're the
one that needs to define the vtable pointer or not
* Should the vtable be the first element in the type? If there's a
non-dynamic base type, we could have a layout that's `{<non-dynamic base
type>, vtable ptr, <derived members>}`? Derived types would still be
able to uniquely identify where their vtable pointer is just fine... -
and the vtable pointer is, in a sense, a member of that intermediate
type, so it does seem a bit strange to force it to the front - but I
guess it's probably more efficient in some ways?
Open to any other suggestions/advice/thoughts on the direction, etc.
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
|
||
|
Jon Ross-Perkins
|
77facdd775 |
Remove unused benchmark_main.h (#4409)
This was refactored to Testing::GetExePath, but apparently the header was missed. |
||
|
Jon Ross-Perkins
|
e2256516e8 |
Fix InitLLVM argv (#4405)
`args_.push_back(nullptr);` can resize `args_`, invalidating `argv`. The order needs to be switched. |
||
|
Jon Ross-Perkins
|
9b0519d236 |
Convert CommandLine member references to pointers (#4301)
This follows up on a [style question](https://discord.com/channels/655572317891461132/821113559755784242/1283516297686286377) about whether to prefer reference members or pointers. This PR converts to pointers as a demonstration of that style choice. Note, I'm trying to update constructors to match use of `*` based on whether they keep a reference. I'm removing a few `const&` uses where no reference was kept (i.e., it was just copied, and didn't seem worth a move). I'm changing `AddArgImpl` to return an `Arg*` because it just gets passed to a constructor, seems simpler this way. |
||
|
Chandler Carruth
|
1d904556ef |
Remove [[clang::preserve_most]] (#4319)
These appear to be causing some subtle misinteractions with MSan that we don't understand, and may be a compiler bug. =/ Fortunately, they weren't essential to the performance gains so just remove them for now. When benchmarked on an x86 server, where I would expect this to be more important due to relatively few named registers, the performance change appears to be either an improvement or in the noise. Huge credit to Jon for tracking down that this is related to the MSan issues. |
||
|
4845f40dff |
Switch CARBON_CHECK to a format string API (#4285)
This switches `DCHECK` and `FATAL` as well. The goal is to reduce the code size impact of these assertions so that we can keep more of them enabled. Currently, the largest cost I see from `CHECK` is not the actual check or the cold code itself, but actually the failure to inline trivial functions due to the presence of the cold code. This means that our goal isn't to reduce apparent code size in the final binary but the LLVM IR cost assessed for these routines in the inliner, which closely correlates with code size but is a bit different. As discussed in #4283, experimentation shows that a single function call with a minimal number of arguments is the lowest cost model for these. This is easily achieved with a format-string API that internally uses `llvm::formatv`. This PR is essentially the `CHECK` version of #4283. However, the check macros are substantially harder to make work with both format strings and streaming because they also take a condition. Also, unexpectedly, I was very successful at devising a regular expression based automated rewrite from the streaming to the format string form with only low 10s of manual fixes. This includes compacting strings broken up across lines, etc. Given how well that went, I've prepared this PR which just directly switches to the format string API and migrate everything to use it. One nice side-effect is that the format string approach ends up greatly simplifying the implementation here as well. This is ... *shockingly* effective. Parsing speeds up by more than 3% with just this change. And checking speeds up by **8%** with this change alone: ``` BM_CompileAPIFileDenseDecls<Phase::Parse>/256 86.3µs ± 1% 82.9µs ± 1% -3.94% (p=0.000 n=17+19) BM_CompileAPIFileDenseDecls<Phase::Parse>/1024 431µs ± 1% 415µs ± 1% -3.76% (p=0.000 n=18+19) BM_CompileAPIFileDenseDecls<Phase::Parse>/4096 1.77ms ± 1% 1.71ms ± 1% -3.18% (p=0.000 n=18+19) BM_CompileAPIFileDenseDecls<Phase::Parse>/16384 7.44ms ± 1% 7.17ms ± 2% -3.56% (p=0.000 n=18+20) BM_CompileAPIFileDenseDecls<Phase::Parse>/65536 30.7ms ± 1% 29.7ms ± 1% -3.15% (p=0.000 n=18+20) BM_CompileAPIFileDenseDecls<Phase::Parse>/262144 131ms ± 1% 127ms ± 1% -2.81% (p=0.000 n=18+18) BM_CompileAPIFileDenseDecls<Phase::Check>/256 878µs ± 2% 800µs ± 1% -8.91% (p=0.000 n=19+20) BM_CompileAPIFileDenseDecls<Phase::Check>/1024 1.88ms ± 2% 1.72ms ± 1% -8.56% (p=0.000 n=19+20) BM_CompileAPIFileDenseDecls<Phase::Check>/4096 5.78ms ± 2% 5.28ms ± 1% -8.70% (p=0.000 n=20+18) BM_CompileAPIFileDenseDecls<Phase::Check>/16384 21.9ms ± 1% 20.1ms ± 1% -8.02% (p=0.000 n=18+20) BM_CompileAPIFileDenseDecls<Phase::Check>/65536 90.4ms ± 2% 83.1ms ± 1% -8.04% (p=0.000 n=19+20) BM_CompileAPIFileDenseDecls<Phase::Check>/262144 381ms ± 2% 352ms ± 1% -7.79% (p=0.000 n=19+19) ``` --------- Co-authored-by: Richard Smith <richard@metafoo.co.uk> Co-authored-by: josh11b <15258583+josh11b@users.noreply.github.com> |
||
|
Jon Ross-Perkins
|
de57c9988c |
Break out driver environment info into its own type. (#4299)
I want to split commands out so that we don't keep piling onto driver (particularly as I'm eyeing clang-related commands). This extracts out the DriverEnv so that it can be easily shared, with the CompilationUnit as an example. CARBON_VLOG_TO is to remove the vlog_stream_ requirement of CARBON_VLOG. |
||
|
Chandler Carruth
|
0c8ab663c9 |
Migrate all CARBON_VLOG to the format string variant. (#4284)
This mostly uses a hilarious set of regular expressions to mechanically switch all but two uses, and then manually fixed the last two. There weren't too many. Also simplifies the `vlog` implementation now that it's all going through a format string. This alone has a nice impact on parse and check of about 2% and 1% respectively. The impact on lex in my timings looks like noise (no change in instruction count, unlike the other phases). ``` name old cpu/op new cpu/op delta BM_CompileAPIFileDenseDecls<Phase::Lex>/256 39.1µs ± 3% 38.1µs ± 2% -2.42% (p=0.000 n=20+19) BM_CompileAPIFileDenseDecls<Phase::Lex>/1024 187µs ± 3% 183µs ± 1% -2.30% (p=0.000 n=20+20) BM_CompileAPIFileDenseDecls<Phase::Lex>/4096 776µs ± 4% 756µs ± 1% -2.62% (p=0.000 n=20+20) BM_CompileAPIFileDenseDecls<Phase::Lex>/16384 3.36ms ± 1% 3.33ms ± 1% -0.90% (p=0.000 n=18+18) BM_CompileAPIFileDenseDecls<Phase::Lex>/65536 14.4ms ± 2% 14.2ms ± 1% -1.41% (p=0.000 n=20+20) BM_CompileAPIFileDenseDecls<Phase::Lex>/262144 65.7ms ± 1% 65.2ms ± 2% -0.86% (p=0.002 n=19+20) BM_CompileAPIFileDenseDecls<Phase::Parse>/256 87.5µs ± 1% 86.3µs ± 1% -1.43% (p=0.000 n=19+20) BM_CompileAPIFileDenseDecls<Phase::Parse>/1024 438µs ± 2% 431µs ± 1% -1.54% (p=0.000 n=19+20) BM_CompileAPIFileDenseDecls<Phase::Parse>/4096 1.81ms ± 2% 1.77ms ± 1% -2.12% (p=0.000 n=20+20) BM_CompileAPIFileDenseDecls<Phase::Parse>/16384 7.54ms ± 1% 7.43ms ± 1% -1.44% (p=0.000 n=19+20) BM_CompileAPIFileDenseDecls<Phase::Parse>/65536 31.2ms ± 1% 30.6ms ± 1% -2.03% (p=0.000 n=20+20) BM_CompileAPIFileDenseDecls<Phase::Parse>/262144 133ms ± 1% 130ms ± 1% -1.85% (p=0.000 n=20+20) BM_CompileAPIFileDenseDecls<Phase::Check>/256 882µs ± 1% 878µs ± 1% -0.52% (p=0.001 n=17+19) BM_CompileAPIFileDenseDecls<Phase::Check>/1024 1.90ms ± 2% 1.88ms ± 1% -1.17% (p=0.000 n=19+19) BM_CompileAPIFileDenseDecls<Phase::Check>/4096 5.85ms ± 2% 5.76ms ± 1% -1.43% (p=0.000 n=20+19) BM_CompileAPIFileDenseDecls<Phase::Check>/16384 22.2ms ± 2% 21.9ms ± 2% -1.20% (p=0.000 n=20+19) BM_CompileAPIFileDenseDecls<Phase::Check>/65536 91.2ms ± 2% 90.3ms ± 1% -1.00% (p=0.000 n=20+19) BM_CompileAPIFileDenseDecls<Phase::Check>/262144 382ms ± 1% 380ms ± 1% -0.51% (p=0.003 n=18+19) ``` |
||
|
|
e48101b608 |
Switch CARBON_VLOG to support a format string API. (#4283)
The goal is to replace our stream operator APIs with format string APIs that can be made to have much less impact on inlining and other optimizations of the performance critical path through the code. Several experiments show that the most compact representation we can arrange for is one that calls an uninlined function and passes a minimal number of arguments to it. It doesn't help to do any work to minimize the arguments such as building a lambda -- the cost of extra code to merge the arguments is likely to outweigh the benefit. Initial experiments showed that switching a hot but uninlined function to this new API enabled inlining and the subsequent performance improvement. This also adds a 'TemplateString` utility that allows using a string literal as a template parameter. This is useful to remove the format string itself from the arguments passed to the function by passing it as a template argument instead. Currently, support is left in place for both APIs because with `CARBON_VLOG` we can detect whether or not any message was provided expecting a format string. This should allow incrementally migrating code to this API. I've added some test coverage in this PR, but I'll separate out any switching of parts of the codebase over. The goal is to eventually replace all the usages and remove the streaming support entirely. This PR doesn't update `CARBON_CHECK` in the same way because it is substantially more complex to switch. I have a few experimental PRs looking at that and will discuss how best to approach this with the specific challenges check presents separately. But the goal is for all of the macro-based output APIs to move to format strings rather than streams. --------- Co-authored-by: josh11b <15258583+josh11b@users.noreply.github.com> Co-authored-by: Richard Smith <richard@metafoo.co.uk> |
||
|
Jon Ross-Perkins
|
43c6259fb2 |
Update LLVM and fix formatv issues. (#4282)
https://github.com/llvm/llvm-project/pull/105745 increased validation of formatv requirements, this fixes a couple issues. Note the CommandLine case was untested, and caught separately. |
||
|
Richard SmithandJon Ross-Perkins
|
187a3608df |
Use As and ImplicitAs interfaces for conversions. (#4209)
Add these interfaces to the core library. For now, they're two separate interfaces because we don't yet support one interface extending another. This collapses a lot of the layering in check: for example, the call building logic depends on implicit conversions, conversions now depend on the overloaded operator machinery, and that machinery depends on building calls. In passing, improve the diagnostics for failing to find a name required from the prelude. Also convert all the transitively-called code from `NodeId` to `LocId` given the latter is what the conversion machinery has available. --------- Co-authored-by: Jon Ross-Perkins <jperkins@google.com> |
||
|
Chandler Carruth
|
5d0ec91c20 |
Collection of minor tweaks to get approx. 10-15% compile time (#4245)
Most of these are about enabling inlining, in a couple of cases moving code to a header and throughout switching to `CARBON_DCHECK`. The code size of `CARBON_CHECK` seems to make inliing quite unreliable. I'm going to think about whether there are ways to improve this, but a reasonably small number of these seem worth switching for now to get some compile time savings. Also moves VLOG out of the hot path which helps a bit as well. All combined, this net a bit over 10%, although it varies a bit exactly how much. We're now pretty consistently over 800k lines/second for check in the compilation benchmark for files >=4k lines, which makes me happy. That's remarkably close to our original target. Not really planning to keep optimizing here, just was glancing at the profile and many of these stood out to me and were easy to fix. |
||
|
David Blaikie
|
5a11048c34 |
Remove some explicit (Mutable)ArrayRef constructions (#4238)
Rely on implicit conversion in call sites and initialization. Removing the explicit conversions is only code simplication. Moving from `auto x = Y(z)` to `Y x = z;` helps ensure that only implicit constructors/conversions are happening (whereas the prior syntax allows explicit conversions) which can help with readability since implicit conversions are generally "less complex"/risky/attention-requiring. |
||
|
Chandler Carruth
|
72cb9d0d06 |
Refactor testing exe path and benchmark main handling. (#4216)
Consolidates both main libraries into `//testing/base`, and factors out the exe path handling for benchmarks and unit tests into a common library to remove duplication. Refactors how that logic is managed to be cleaner and avoid a confusing bool that came up in code review. Updates all the tests and benchmarks that use these. I still need to update other benchmarks to use the same main, but I wanted to keep this PR somewhat minimal. This also fixes a bug noticed in passing that the compilation benchmark didn't have the required dependency on the benchmark library itself, just the benchmark main library. |
||
|
|
a9c815c9f4 |
Introduce a source generator and end-to-end compile benchmarks (#4124)
The big addition here is a very, very rough and very early skeleton of a source code generator framework. This builds upon the lexers identifier synthesis logic, improving on its framework and wiring it up with the most rudimentary of source file generation. This is just enough to roughly replicate my "big API file" source code benchmarks. The source generation works *very* hard to both vary the structure and content of the source as much as possible while ensuring the same *total* amount of each construct is in use, from bytes in identifiers to line breaks, parameters, etc. This lets us generate randomly structure inputs that should consistently take the exact same amount of total work to compile. The complex identifier synthesis logic from the lexer's benchmark is moved over here and the lexer uses APIs in the source generator for identifiers. The other source synthesis in the lexer's benchmark isn't yet moved over, but should likely be slowly absorbed here as it can be refactored into a more principled and re-usable form. Some bits may stay of course if they're just too lexer-specific. Next, this adds a simple end-to-end compile benchmark for the driver that directly and much more clearly reproduces all the measurements I've done manually up until now. It should also be easy to extend to more patterns over time as we add support to the source generator to produce those patterns. Last but not least, I've added a tiny CLI to the source generator so that you can generate source code manually. This is especially nice for generating demo source code to actually run through the driver or look at in an editor. The CLI can also generate C++ source code which lets us do some minimal comparative benchmarking between Carbon and C++/Clang. There are huge number of TODOs in the source generation framework. This is going to be a large ongoing effort I suspect. There are also a bunch of rough edges I've left to try and get this out for review sooner. I've left TODOs for refactorings that really need to be done here, but hoping these can maybe be follow-ups. If not, please flag and I'll try to layer them on here. Sample compile benchmark output, nicely showing where we are w.r.t. our goal speeds (2x behind on lex and check, 5x on parse) at least on a recent AMD server CPU: ``` ------------------------------------------------------------------------------------------------------ Benchmark Time CPU Iterations Lines ------------------------------------------------------------------------------------------------------ BM_CompileAPIFileDenseDecls<Phase::Lex>/256 29420 ns 29419 ns 22860 6.62847M/s BM_CompileAPIFileDenseDecls<Phase::Lex>/1024 146130 ns 146128 ns 4840 6.69959M/s BM_CompileAPIFileDenseDecls<Phase::Lex>/4096 601584 ns 601577 ns 1020 6.69573M/s BM_CompileAPIFileDenseDecls<Phase::Lex>/16384 2547578 ns 2547313 ns 280 6.404M/s BM_CompileAPIFileDenseDecls<Phase::Lex>/65536 10816591 ns 10816389 ns 80 6.05193M/s BM_CompileAPIFileDenseDecls<Phase::Lex>/262144 52191320 ns 52189828 ns 20 5.02261M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/256 101706 ns 101698 ns 6900 1.91745M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/1024 512161 ns 512162 ns 1380 1.9115M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/4096 2078426 ns 2078430 ns 340 1.938M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/16384 8795786 ns 8795583 ns 100 1.85468M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/65536 35073596 ns 35072973 ns 20 1.86639M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/262144 151100688 ns 151097370 ns 20 1.73483M/s BM_CompileAPIFileDenseDecls<Phase::Check>/256 957059 ns 957049 ns 740 203.751k/s BM_CompileAPIFileDenseDecls<Phase::Check>/1024 1956134 ns 1955985 ns 360 500.515k/s BM_CompileAPIFileDenseDecls<Phase::Check>/4096 5797864 ns 5797417 ns 120 694.792k/s BM_CompileAPIFileDenseDecls<Phase::Check>/16384 21219608 ns 21217584 ns 40 768.843k/s BM_CompileAPIFileDenseDecls<Phase::Check>/65536 96311116 ns 96302334 ns 20 679.734k/s BM_CompileAPIFileDenseDecls<Phase::Check>/262144 371637963 ns 371609964 ns 20 705.387k/s ``` Lest someone think this is *bad*, the fact that we're already within 2x of our rather audacious goals makes me quite happy. =D --------- Co-authored-by: Jon Ross-Perkins <jperkins@google.com> Co-authored-by: Richard Smith <richard@metafoo.co.uk> |
||
|
Jon Ross-Perkins
|
efa158d496 |
Refactor InstBlockStack to use ArrayStack. (#4104)
The use of ArrayStack here is intended to simplify the logic, and also make better use of the inst heap allocations. Prior changes #4101 and #4103 removed the less related logic from InstBlockStack, although #4103 is the actual part that blocked using ArrayStack. BTW, note the PrintForStackDump implementation was incorrect because it didn't apply size_. This simplification fixes the issue. |