[flang-commits] [clang-tools-extra] [compiler-rt] [llvm] [clang] [flang] [clang] Add `::_placement_new` expression for built-in global placement new (PR #72209)

[via flang-commits]

MaxEW707 wrote:

I was able to do a test on one of our smaller internal projects that uses a custom vendor clang and a custom vendor stl for this vendors platform.
I am planning to get a build of my fork for Linux and macOS so I can test against libcxx directly and test on some of our larger projects.
I am planning to test on some open-source projects in the near future as well.

The `placement_new.h` header that was used for the test looked as follows
```
#ifdef _TEST_INCLUDE_NEW
#include <new>
#else
void*  operator  new(decltype(sizeof(int)),  void*)  noexcept;
#endif

#define MY_PLACEMENT_NEW(p) ::new(p)
```
This test just show cases the build time reduction from including this vendor's `<new>` header and simulates being able to use `::_placement_new` without a header include from the stl since this vendor's stl definitions for operator new do not conflict with our declaration of operator new.

This vendor's `<new>` header takes 29 ms to parse on my machine with their clang.
A clean debug build without `<new>` included takes 7 minutes and 54 seconds.
A clean debug build with `<new>` included takes 8 minutes and 16 seconds.
That is a difference of 22 seconds with just one include plus all its transitives removed.

As a reference on the same machine with a Ubuntu 20.04 WSL image with clang-10 installed from apt libc++ `<new>` takes 72 ms to parse and libstdc++ `<new>` takes 24 ms.
As a reference on the same machine with clang-cl 16.0.5 shipped with VS 17.7, msvc `<new>` takes 51 ms to parse.

I also want to note that it is a lot easier for us to guarantee behaviour from the compiler than to rely on vendor stl's that change as the cpp standard changes or whose headers parse times change between different toolchain versions that we need to support.

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