This change is causing test regressions, e.g::

I did some local work to make this build and pass almost all tests on Linux as well, not to make use of the multi-process features but just to avoid having a separate "for Windows only" branch, and to ensure tests pass across platforms. Unfortunately my change is not at all acceptable for inclusion because it's extremely Linux-specific, and Unix/Program.inc very explicitly says "only use generic UNIX code here". I use pidfds and a timerfd combined with epoll_wait to implement sys::WaitMany. It works well, but I'd be concerned about how to implement this as smoothly for any other *nix platform. pidfd/timerfd/epoll made it downright easy, but I started off trying to look at options that would work more universally on e.g. Linux *and* the BSDs, but I couldn't find anything that wouldn't require building a Rube-Goldberg machine juggling timers, alarms, signals, etc, etc.

In D72404#1820461, @merge_guards_bot wrote:

Unit tests: fail. 61858 tests passed, 1 failed and 781 were skipped.

failed: Clang.CodeGen/thinlto-debug-pm.c

OK, those two problems were actually easy enough to fix.

I rebased this myself on the release_90 branch and I was pleasantly surprised that I got the merge right on the first try (?!), and it actually works well without any significant changes (other than merge conflict resolutions).

OK, that makes sense. So this change would not enforce -O2/-O3 for the bitcode emission, but would enforce one of the two for the LTO phase.

Two things:

Also this maybe an independent change, but:

In D17289#424618, @DavidKreitzer wrote:

Our plan is to first fix the register allocator to bias register assignment choices to hide false dependences. If there is a true dependence on the destination register, then there is no additional cost for the false dependence. So, for example, we will strive to generate

popcnt %rax, %rax
popcnt (%rcx), %rcx

rather than

xor %rdx, %rdx
popcnt %rax, %rdx
xor %rbx, %rbx
popcnt (%rcx), %rbx

Also I just tested the current patch revision. There's an error in how it is checking whether the destination register is used as the input. The input of popcnt can be a memory location, and the destination register may be part of the address calculation:

Sorry to gravedig, but this hasn't been updated in months. Has this been worked on at all recently?