[all-commits] [llvm/llvm-project] e66500: [Support] On Windows 11 and Windows Server 2022, f...

[Alexandre Ganea via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e66500c7749578cf5e1372d0b52781259cb1fa28
      https://github.com/llvm/llvm-project/commit/e66500c7749578cf5e1372d0b52781259cb1fa28
  Author: Alexandre Ganea <alex_toresh at yahoo.fr>
  Date:   2023-01-06 (Fri, 06 Jan 2023)

  Changed paths:
    M llvm/docs/ReleaseNotes.rst
    M llvm/include/llvm/Support/Windows/WindowsSupport.h
    M llvm/lib/Support/Windows/Process.inc
    M llvm/lib/Support/Windows/Threading.inc
    M llvm/unittests/Support/ThreadPool.cpp

  Log Message:
  -----------
  [Support] On Windows 11 and Windows Server 2022, fix an affinity mask issue on large core count machines

Before Windows 11 and Windows Server 2022, only one 'processor group' is assigned by default to a starting process, then the program is responsible for dispatching its own threads on more 'processor groups'. That is what 8404aeb56a73ab24f9b295111de3b37a37f0b841 was doing, allowing LLVM tools to automatically use all hardware threads in the machine.

After Windows 11 and Windows Server 2022, the OS takes care of that. This has an adverse effect reported in #56618 which is that using `GetProcessAffinityMask()` API in some edge cases seems buggy now. That API is used to detect if an affinity mask was set, and adjust accordingly the available threads for a ThreadPool.

With this patch, on one hand, we let the OS dispatch threads on all 'processor groups', but only for Windows 11 & Windows Server 2022 and after. We retain the old behavior for older OS versions. On the other hand, a workaround was added to mitigate the `GetProcessAffinityMask()` issue described above (see Threading.inc, L226).

Differential Revision: https://reviews.llvm.org/D138747