llvm-project.git/llvm/lib/Support/Program.cpp, branch users/nico/python-1

[Support] Construct SmallVector with ArrayRef (NFC) (#137586)

2025-04-29T05:25:17+00:00

Reland "[llvm][Support] Add support for executing a detached process (#81708)" (#83367)

2024-03-07T04:45:11+00:00

Relands #81708, which was reverted by
f410f74cd5b26319b5796e0404c6a0f3b5cc00a5, now with a corrected unit
test. Origionally the test failed on Windows when run with lit as
`GetConsoleWindow` could not retrieve a window handle regardless of
whether `DetachProcess` was `true` or `false`. The test now uses
`GetStdHandle(STD_OUTPUT_HANDLE)` which does not rely on a console
window existing. Original commit message below.

Adds a new parameter, `bool DetachProcess` with a default option of
`false`, to `llvm::sys::ExecuteNoWait`, which, when set to `true`,
executes the specified program without a controlling terminal.

Functionality added so that the module build daemon can be run without a
controlling terminal.

Revert "[llvm][Support] Add support for executing a detached process (#81708)"

2024-02-27T02:40:21+00:00

This reverts commit 86f6caa562255f81b93e72a501a926b17f5ad244. Unit test
was failing on a few windows build bots

[llvm][Support] Add support for executing a detached process (#81708)

2024-02-27T02:04:11+00:00

Adds a new parameter, `bool DetachProcess` with a default option of
`false`, to `llvm::sys::ExecuteNoWait`, which, when set to `true`,
executes the specified program without a controlling terminal.

Functionality added so that the module build daemon can be run without a
controlling terminal.

Support: Make Wait's SecondsToWait be std::optional [NFC]

2022-12-14T14:56:10+00:00

I found the interaction between SecondsToWait and
WaitUntilChildTerminates confusing. Rather than have a boolean to
ignore the value of SecondsToWait, combine these into one Optional
parameter.

Support: Convert Program APIs to std::optional

2022-12-01T22:00:44+00:00

Cleanup include: TableGen

2022-03-11T10:41:32+00:00

This also includes a few cleanup from Support.

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121331

Re-land [Support] On Windows, take the affinity mask into account

2021-01-14T22:03:22+00:00

The number of hardware threads available to a ThreadPool can be limited if setting an affinity mask.
For example:

    > start /B /AFFINITY 0xF lld-link.exe ...

Would let LLD only use 4 hyper-threads.

Previously, there was an outstanding issue on Windows Server 2019 on dual-CPU machines, which was preventing from using both CPU sockets. In normal conditions, when no affinity mask was set, ProcessorGroup::AllThreads was different from ProcessorGroup::UsableThreads. The previous code in llvm/lib/Support/Windows/Threading.inc L201 was improperly assuming those two values to be equal, and consequently was limiting the execution to only one CPU socket.

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

Revert "[Support] On Windows, take the affinity mask into account"

2021-01-14T02:34:54+00:00

This reverts commit 336ab2d51dfdd5ca09c2a9c506453db4fe653584.

[Support] On Windows, take the affinity mask into account

2021-01-14T02:00:09+00:00

The number of hardware threads available to a ThreadPool can be limited if setting an affinity mask.
For example:

> start /B /AFFINITY 0xF lld-link.exe ...

Would let LLD only use 4 hyper-threads.

Previously, there was an outstanding issue on Windows Server 2019 on dual-CPU machines, which was preventing from using both CPU sockets. In normal conditions, when no affinity mask was set, ProcessorGroup::AllThreads was different from ProcessorGroup::UsableThreads. The previous code in llvm/lib/Support/Windows/Threading.inc L201 was improperly assuming those two values to be equal, and consequently was limiting the execution to only one CPU socket.

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