[OpenMP] Add num_threads clause list format and strict modifier support

[TerryLWilmarth]

Add support to the runtime for 6.0 spec features that allow num_threads clause to take a list, and also make use of the strict modifier. Provides new compiler interface functions for these features.

[shiltian]

Can we have tests?

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[shiltian]

LGTM. Will the front end support be upstreamed as well?

[shiltian]

This will not cause issue on Windows anymore?

[jpeyton52]

Right, you can add exported symbols just by name now. Older symbols keep their ordinal number.

[jpeyton52]

LGTM

[mstorsjo]

This change causes failed tests on i386: https://github.com/mstorsjo/llvm-mingw/actions/runs/9654575386/job/26643787120

# .---command stderr------------
# | OMP: Error #137: Cannot create thread.
# | OMP: System error #8: (No system error message available)
# `-----------------------------
# error: command failed with exit status: 3

I presume the test spawns a very large number of threads? Can it be marked with UNSUPPORTED for 32 bit environments somehow?

[TerryLWilmarth]

This change causes failed tests on i386: https://github.com/mstorsjo/llvm-mingw/actions/runs/9654575386/job/26643787120

# .---command stderr------------
# | OMP: Error #137: Cannot create thread.
# | OMP: System error #8: (No system error message available)
# `-----------------------------
# error: command failed with exit status: 3

I presume the test spawns a very large number of threads? Can it be marked with UNSUPPORTED for 32 bit environments somehow?

Yes, in the second to last case, the test uses a pretty deep level of nesting, and tests the num_threads clause list at two different nesting levels, so it will generate a lot of threads. We could modify the test so that the list used at the outer level is something like 3,1 and inner level is 3,1, which should create 9 threads at most. That should be adequate to show the feature is working correctly. Would that work for this system?

[mstorsjo]

This change causes failed tests on i386: https://github.com/mstorsjo/llvm-mingw/actions/runs/9654575386/job/26643787120

# .---command stderr------------
# | OMP: Error #137: Cannot create thread.
# | OMP: System error #8: (No system error message available)
# `-----------------------------
# error: command failed with exit status: 3

I presume the test spawns a very large number of threads? Can it be marked with UNSUPPORTED for 32 bit environments somehow?

Yes, in the second to last case, the test uses a pretty deep level of nesting, and tests the num_threads clause list at two different nesting levels, so it will generate a lot of threads. We could modify the test so that the list used at the outer level is something like 3,1 and inner level is 3,1, which should create 9 threads at most. That should be adequate to show the feature is working correctly. Would that work for this system?

I'm pretty sure that 9 threads should be quite doable to spawn. If you put up a PR to do this modification, I might be able to test it.

[mstorsjo]

Ping - can you post the change (or provide a link to it?) for reducing the number of threads here, to get the tests back to passing again?

[TerryLWilmarth]

Working on it.

[TerryLWilmarth]

Martin, will it work with 36 threads? I have a pull request for that change up now. Using 1 in the outer level list has exposed what appears to be a non-trivial bug. I'll work on that and add the triggering test case when fixed. Let me know if the 36 threads case will work for you for now. Thanks!