LGMT too!

Update non-remark tests

In D102107#2819869, @lebedev.ri wrote:

(This is not offload-specific, right?)
This does not bring any compatibility issues, right?

Rebase to NewGlobalization and amend

LGTM, minor comment

In D102107#2776237, @jdoerfert wrote:

This allows us to remove the switch in the device runtime, right?

Use non-aggregate captured args and outlining for ordered codegen

Add tests

Ping @vsk! Waiting for your decision :)

Update for correct implicit checks

In D101849#2766411, @mikerice wrote:

In D101849#2764825, @ABataev wrote:

No, it is not required. Most probably, needed to simplify test checks, nothing else.

Thanks. I'd like to remove the "REQUIRES: x86-registered-target", the -O1 for CHECK6,10, and regenerate the CHECK lines. Unfortunately I am seeing this mangling issue (https://bugs.llvm.org/show_bug.cgi?id=49767) when running the script. @ggeorgakoudis, how did you get past this to generate the CHECK lines in your change?

Update correction for implicit simd checks

LG, some remarks

In D96854#2709726, @vsk wrote:

Oh, I think I see what you meant - was it that the CE analysis cache can be re-used? The motivation there was eliminating quadratic compile-time for repeated outlining (D68616); with that change some cached analysis of the caller became reusable, but not the extractor instance itself.

Update fopenmp-simd handling to avoid duplicate implicit checks

Update regex for removing old checklines

In D101849#2741980, @DavidSpickett wrote:

I've required X86 target for this test to get our bots green again.

Update for comments

Update by Johanne's correction on the source of non-determinism

More updates to tests

Update tests

Update test

Does this update need a test?

I'm trying to understand the functionality you want to achieve. Doesn't using different prefixes avoid merging already? The test does not seem to exercise your extensions.

In D95976#2725027, @protze.joachim wrote:

Please update the test with a NFC commit.

In D101123#2712461, @jdoerfert wrote:

In D101123#2712248, @ggeorgakoudis wrote:

Does this work correctly with a nested parallel region in SPMD mode? I think the zeroing-out of the parallel-level is needed for this case.

The parallel level in SPMD mode can never be zero. It is 1 in the beginning and then can only be higher as we enter serialized parallel regions (Inc/Dec level in *_serialized_parallel).

Does this work correctly with a nested parallel region in SPMD mode? I think the zeroing-out of the parallel-level is needed for this case.

@vsk I'll re-structure the implementation to use internal state and an addArgExludedFromAggregate interface. I don't have/can't think right now a use case for the flexibility I'm proposing.

In D96854#2695426, @vsk wrote:

for example it makes possible to extract the same region with different exclusions without creating another CodeExtractor instance,

As extractCodeRegion mutates the original function, I assumed it was not possible to reuse a CodeExtractor instance in this way. Is there an in-tree example of CE instance reuse I can take a look at?

Fix clang-format

Add tests, reduce microtask cases to avoid stack problems

Fix

Update for comments, fixes

Update for comments, fix for windows fix

Fix for getThreadLimit

Hi @Meinersbur (got word you are a windows user), @jdoerfert, could I ask your help in detecting why the clang tests on windows are failing? There are two failures I'm spotting, one is that calls to llvm.nvvm intrinsics seem transposed (https://reviews.llvm.org/harbormaster/unit/view/552591/) and another that attribute regexes are not recognized (https://reviews.llvm.org/harbormaster/unit/view/552593/ at nvptx_target_codegen.cpp:723:17). Maybe there is something else I'm missing and I'd appreciate the extra eyeballing on the problem.

Fix llvm test

Add aux-triple to one test, check unit test builder on windows

Add tests, update OpenMPOpt, rebase to main

In D96854#2645458, @vsk wrote:

Thanks for explaining. I'd suggest making ExcludedAggArgs part of a CodeExtractor instances internal state: e.g. the client may call CE.addArgExludedFromAggregate(Value *) some number of times before CE.extractCodeRegion(). This way, the client doesn't need to maintain a SetVector, and the rest of the interface isn't polluted with an option that's specific to the AggregateArg case.

Update for comments