llvm-project.git/llvm/lib/Support/Windows/Threading.inc, branch users/nico/python-1

[Support] Include Support/thread.h before api implementations (#111175)

2024-10-10T04:45:29+00:00

This header was included after the implementations to work around an
issue with FreeBSD, however, , this causes some issues when
dllexport\explicit visibility
attributes will be added to the headers on Windows, since the
definitions need to see the declarations for the attributes to apply.

This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and plugins on
windows.

---------

Co-authored-by: Tom Stellard

[Support] Use llvm::popcount (NFC)

2023-02-12T21:39:18+00:00

This should fix builds on Windows.

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

2023-01-06T22:03:43+00:00

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

[Support] llvm::Optional => std::optional

2022-12-16T08:49:10+00:00

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

[llvm] Use std::nullopt instead of None in comments (NFC)

2022-12-07T06:45:17+00:00

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

[llvm] Use std::nullopt instead of llvm::None (NFC)

2022-12-06T07:50:04+00:00

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

Threading: Convert Optional to std::optional

2022-12-01T23:57:17+00:00

dthorn: Relanding after fix-forward.

Revert "Threading: Convert Optional to std::optional"

2022-12-01T23:42:25+00:00

This reverts commit 5e50b8089aee249d77542ea858d956568ec6581f.

This commit breaks the build for BOLT:
  bolt/lib/Profile/DataAggregator.cpp:264:66: error: no viable
  conversion from 'Optional[3]' to
  'ArrayRef>'

Threading: Convert Optional to std::optional

2022-12-01T22:36:05+00:00

[Support] Move getHostNumPhysicalCores to Threading.h

2022-11-29T13:14:13+00:00

This change is focussed on simplifying `Support/Host.h` to only do
target detection. In this case, this function is close in usage to
existing functions in `Support/Threading.h`, so I moved it into there.
The function is also renamed to `llvm::get_physical_cores()` to match
the style of threading's functions.

The big change here is that now if you have threading disabled,
`llvm::get_physical_cores()` will return -1, as if it had not been able
to work out the right info. This is due to how Threading.cpp includes
OS-specific code/headers. This seems ok, as if threading is disabled,
LLVM should not need to know the number of physical cores.

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