Commit Graph
10 Commits
Author SHA1 Message Date
Thomas Köppe bf32da8dad Add missing standard library header inclusions (#5316)
Discovered by clang-tidy.
2025-04-17 15:37:57 +00:00
Jon Ross-Perkins 197e784140 Add parsing for partial types (#5009) 2025-02-25 02:07:10 +00:00
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`
2025-02-24 22:41:59 +00:00
Chandler Carruth 02c263294c Move the constants in the precedence table into the header. (#4308)
Getting the basic constants is actually quite hot in the parser, and is
spending all of its time in memory stalls due to touching the call stack
just to return a constant when these are out-of-line.

This alone is worth another 8% improvement in parsing, and 2% in syntax
checking:
```
name                                               old cpu/op   new cpu/op   delta
BM_CompileAPIFileDenseDecls<Phase::Lex>/256        37.7µs ± 1%  37.5µs ± 2%  -0.58%  (p=0.019 n=19+18)
BM_CompileAPIFileDenseDecls<Phase::Lex>/1024        181µs ± 1%   179µs ± 2%  -0.95%  (p=0.001 n=20+20)
BM_CompileAPIFileDenseDecls<Phase::Lex>/4096        743µs ± 1%   736µs ± 2%  -0.85%  (p=0.001 n=20+19)
BM_CompileAPIFileDenseDecls<Phase::Lex>/16384      3.30ms ± 1%  3.25ms ± 2%  -1.48%  (p=0.000 n=17+19)
BM_CompileAPIFileDenseDecls<Phase::Lex>/65536      14.2ms ± 1%  13.9ms ± 2%  -1.95%  (p=0.000 n=17+19)
BM_CompileAPIFileDenseDecls<Phase::Lex>/262144     64.7ms ± 2%  63.8ms ± 2%  -1.30%  (p=0.000 n=18+18)
BM_CompileAPIFileDenseDecls<Phase::Parse>/256      71.0µs ± 1%  65.2µs ± 2%  -8.20%  (p=0.000 n=19+20)
BM_CompileAPIFileDenseDecls<Phase::Parse>/1024      351µs ± 1%   320µs ± 1%  -9.02%  (p=0.000 n=19+20)
BM_CompileAPIFileDenseDecls<Phase::Parse>/4096     1.43ms ± 2%  1.31ms ± 2%  -8.41%  (p=0.000 n=19+20)
BM_CompileAPIFileDenseDecls<Phase::Parse>/16384    6.08ms ± 2%  5.57ms ± 1%  -8.49%  (p=0.000 n=19+19)
BM_CompileAPIFileDenseDecls<Phase::Parse>/65536    25.2ms ± 1%  23.2ms ± 1%  -8.08%  (p=0.000 n=19+19)
BM_CompileAPIFileDenseDecls<Phase::Parse>/262144    109ms ± 1%   101ms ± 1%  -6.93%  (p=0.000 n=19+19)
BM_CompileAPIFileDenseDecls<Phase::Check>/256       752µs ± 1%   744µs ± 1%  -1.07%  (p=0.000 n=19+20)
BM_CompileAPIFileDenseDecls<Phase::Check>/1024     1.62ms ± 1%  1.59ms ± 1%  -1.88%  (p=0.000 n=19+20)
BM_CompileAPIFileDenseDecls<Phase::Check>/4096     4.97ms ± 2%  4.85ms ± 1%  -2.43%  (p=0.000 n=20+20)
BM_CompileAPIFileDenseDecls<Phase::Check>/16384    19.0ms ± 2%  18.5ms ± 2%  -2.32%  (p=0.000 n=19+20)
BM_CompileAPIFileDenseDecls<Phase::Check>/65536    78.8ms ± 2%  76.9ms ± 2%  -2.50%  (p=0.000 n=20+20)
BM_CompileAPIFileDenseDecls<Phase::Check>/262144    334ms ± 1%   327ms ± 2%  -2.29%  (p=0.000 n=20+20)
```
2024-09-13 10:03:21 +00:00
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>
2024-09-12 16:42:08 +00:00
c33c9a02f6 Parse support for where operator (#4275)
Includes support for the `impls`, `=`, and `==` requirement operators to
the right of a `where`, but `and` to allow multiple requirements is
still a TODO.

---------

Co-authored-by: Josh L <josh11b@users.noreply.github.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
2024-09-11 03:17:07 +00:00
935715e704 Implement new precedence from #4075 (#4236)
Co-authored-by: Josh L <josh11b@users.noreply.github.com>
Co-authored-by: Geoff Romer <gromer@google.com>
2024-08-22 22:32:19 +00:00
josh11bandJon Ross-Perkins 5f439b842b Parsing impl...as (#3473)
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
2023-12-09 04:04:00 +00:00
josh11b 11ca083855 Use abbreviation "expr" instead of "expression" (#3375)
Part of switching to the [abbreviations we've decided to
use](https://docs.google.com/document/d/1RRYMm42osyqhI2LyjrjockYCutQ5dOf8Abu50kTrkX0/edit?resourcekey=0-kHyqOESbOHmzZphUbtLrTw#heading=h.pph7i5m5un7q).

I will rename files in a follow-up PR.
2023-11-10 01:32:32 +00:00
Jon Ross-Perkins c555b39a2c Rename parser dir to parse (#3178)
Continuing with #3070. Just a dir and file rename (mostly removing
prefixes, although for parse_tree_fuzzer and parse_tree_file_test I'm
dropping "tree" instead of "parse"). Everything in the parse dir should
be marked as a move.
2023-09-01 01:35:45 +00:00