mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-10-02 22:02:51 +01:00
dfd5fe368d1c13ac6ef302ffe67f6f391ea05021
238
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Thomas Köppe
|
bf32da8dad |
Add missing standard library header inclusions (#5316)
Discovered by clang-tidy. |
||
 Jon Ross-Perkins
|
72cfaad1c7 |
Remove the indirect_value library (#5312)
This was used by explorer, and no longer has uses. |
||
|
Jon Ross-Perkins
|
8c3fa80691 |
Add cc rule wrappers for cc_env (#5277)
Rules executed by bazel don't necessarily have the right environment to find the symbolizer, which was the intent of `cc_env` setting `LLVM_SYMBOLIZER_PATH`. So far, this has kind of been a case-by-case fix, but every so often I'm trying to debug a crash in a test that doesn't provide it. Rather continuing down this route, instead add drop-in wrappers for cc rules so that it's hard to forget. Note `bazel/cc_rules` is intended to mirror `bazel/carbon_rules` and `bazel/cc_toolchains`, rather than `@rules_cc`. AFAICT there isn't a great way to add this as a default for the `bazel run` environment. It's not typically going to be set on its own, forwarding `$PATH` would be too broad, and the [action `env_sets`](https://bazel.build/docs/cc-toolchain-config-reference#using-action-config) I think are not quite what we need (I think those don't include output execution, only compilation). |
||
 Jon Ross-PerkinsandDana Jansens
|
3ae62f8130 |
Rewrite Dump calls to use std::string returns (#5195)
Thought this might be interesting for you to allow more continuous
stream use. Also eliminates the need for `DumpNoNewline`.
```
expr Dump(context, complete_type_id)
(std::string) $0 = "type(inst1553): <builtin i32>; {kind: IntType, arg0: signed, arg1: inst1508, type: type(TypeType)}"
complete_type_id.Dump()
(std::string) $1 = "type(inst1553)"
expr Dump(context, specific_id)
(std::string) $2 = "specific166: {generic: generic0, args: inst_block772}"
expr Dump(context, query_self_const_id)
(std::string) $3 = "concrete_constant(inst1510): {kind: ClassType, arg0: class0, arg1: specific166, type: type(TypeType)}"
expr Dump(context, MakeFacetTypeId(arg))
(std::string) $4 = "facet_type22: {impls interface: interface10}
- interface10: {name: name26, parent_scope: name_scope0} `BitAnd`
complete: complete_facet_type22
- interface10: {name: name26, parent_scope: name_scope0} `BitAnd` (to impl)"
```
---------
Co-authored-by: Dana Jansens <danakj@orodu.net>
|
||
|
Jon Ross-Perkins
|
0d3d829478 |
Cleanup pass over llvm::seq uses (#5185)
I was thinking about this after `seq` changes in #5182, and looked for other uses that might be replaceable. Here's the resulting cleanup around `seq`: - Switch to `enumerate` or `zip` when possible. - `int _` -> `auto _` (it's typically a `size_t`, but there's no reason to cast when unused) - Fix a case of cast style `(size_t)...` -> `static_cast<size_t>(...)` - Switch `(void)close_children_count` to `[[maybe_unused]]` |
||
 Alexander Kornienko
|
b3c7a7e988 |
Fix a compilation error with a recent Clang (#5170)
This fixes a `copy constructor must pass its first argument by reference` compilation error when compiled with a recent enough Clang (after https://github.com/llvm/llvm-project/commit/fe0d3e3764961b62f43f1b129f30aaec5f30bc16, targeted for LLVM 21 release). ``` carbon/lang/common/set.h:81:59: error: copy constructor must pass its first argument by reference 81 | SetView(SetView<std::remove_const_t<KeyT>, KeyContextT> other_view) | ^ ``` |
||
|
Dana Jansens
|
489d5298f2 |
Add a newline to the end of Printable::Dump() (#5155)
This makes it friendlier in interactive debuggers. If you want to print a value without a newline from code, you will have to be calling Print() anyway since Dump() is private, and Print() does not add a newline. |
||
 Boaz Brickner
|
caaeabce09 |
Update comment following a rename (#5139)
Rename: https://github.com/carbon-language/carbon-lang/pull/4100/commits/6da9a9ee19eec002878a0d59a1af00d24f515d9a |
||
|
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) ``` |