[libcxx-commits] [clang] [libcxx] [Clang] Normalize constraints before checking for satisfaction (PR #161671)

[Hans Wennborg via libcxx-commits]

zmodem wrote:

> one way to evaluate the performance impact would be to bootstrap clang itself _with C++20 enabled_.

I looked into this, building a stage0 clang and libc++ configured with:

```
$ cmake -GNinja -Bstage0 -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=OFF -DLLVM_ENABLE_PROJECTS=clang -DLLVM_ENABLE_RUNTIMES='compiler-rt;libcxx;libcxxabi;libunwind' -DLLVM_TARGETS_TO_BUILD=X86 llvm/
```

and then using that to do a debug shared-library build of clang in c++20 mode:

```
$ CC=$PWD/stage0/bin/clang CXX=$PWD/stage0/bin/clang++ CXXFLAGS=-stdlib=libc++ cmake -GNinja -Bstage1 -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_STANDARD=20 -DLLVM_USE_LINKER=lld -DBUILD_SHARED_LIBS=ON -DLLVM_ENABLE_PROJECTS=clang -DLLVM_TARGETS_TO_BUILD=X86 llvm/
$ mkdir -p stage1/lib && cp stage0/lib/x86_64-unknown-linux-gnu/*.so* stage1/lib/
$ rm -f stage1/.ninja_log && time ninja -C stage1 clang
```

The increase from this change is small but measurable: about 5 CPU-minutes, or 1.5 %.

I suppose it makes sense that the difference is smaller, since this codebase has no use of concepts at all besides via the STL, as opposed to Chromium which does seem to have a fair amount of concepts use in its base library, Abseil and so on.

---

I'm not sure how to proceed here. A 16% build time increase (as mentioned up-thread) is very significant for us.

@AaronBallman do you have any thoughts here?

I did see that #61811 mention "We should get performance data for that change and give feedback to WG21 if it looks like this is going to have a significant performance impact." So it sounds like this was somewhat anticipated?

> In the standard, constraint satisfaction checking is done on the normalized form of a constraint.
> 
> Clang instead substitutes on the non-normalized form, which causes us to report substitution failures in template arguments or concept ids, which is non-conforming but unavoidable without a parameter mapping

I don't know much about concepts, but is there some way we could keep the old, fast, code path for most cases, and only use the new more expensive logic when that's not sufficient?

https://github.com/llvm/llvm-project/pull/161671