OpenMP 5.0 metadirective

[alokmishra.besu]

Summary

This patch supports OpenMP 5.0 metadirective features.
It is implemented keeping the OpenMP 5.1 features like dynamic user condition in mind.

A new function, getBestWhenMatchForContext, is defined in llvm/Frontend/OpenMP/OMPContext.h

Currently this function return the index of the when clause with the highest score from the ones applicable in the Context.
But this function is declared with an array which can be used in OpenMP 5.1 implementation to select all the valid when clauses which can be resolved in runtime. Currently this array is set to null by default and its implementation is left for future.

[alokmishra.besu]

clang/include/clang/AST/StmtOpenMP.h

610

In OpenMP 5.0, we do not need to generate every sub-directive. Rather we need to select one (or none) directive and replace metadirective with it. So this is not needed.
Yes with future specifications we will need to include a list of all valid directives which need to be resolved at runtime. That is when we will need to generate and store multiple sub-directives inside the OMPMetaDirective class.

[ABataev]

clang/include/clang/AST/StmtOpenMP.h

610

I think you still need to do it even for 5.0. I don't mean y need to emit the code for every sub-directive, but to generate them in the AST. Even in the example above, when(user={condition(N>10)} is used in the template and N is a template argument, the chosen directive can be selected on the instantiation and, thus, the original templated directive has to contain all possible sub-directives.

[jdoerfert]

clang/include/clang/Serialization/ASTBitCodes.h

1868–1869

Rest was formatted by git clang-format

Please don't format unrelated code.

clang/lib/Parse/ParseOpenMP.cpp

2414

Unfortunately we cannot go to the original code handling since the original code handling assumes that the directive always ends with annot_pragma_openmp_end, while here it will always end with ')'.

Let's add a flag to the original handling to make this possible then. Copying it is going to create more long term problems.

llvm/lib/Frontend/OpenMP/OMPContext.cpp

337 ↗

(On Diff #306974)

Use the getBestVariantMatchForContext interface now and for the 5.1 semantics we introduce the OrderedMatch. That can also be used in the call site declare variant handling which currently calls getBestVariantMatchForContext multiple times.

[alokmishra.besu]

clang/include/clang/Serialization/ASTBitCodes.h

1868–1869

Removed.

clang/lib/Parse/ParseOpenMP.cpp

2414

Done.

[dreachem]

In D91944#2414364, @jdoerfert wrote:

This looks close to an OpenMP 5.0 implementation. I left comments inlined.

We need tests that show how non-selected alternatives *do not* impact the program. As an example, a template instantiation inside of a non-selected alternative is not actually performed.

We also need test with ill-formed metadirectives.

@jdoerfert I'm still trying to understand this thing regarding template instantiations. The spec says that a directive variant associated with a when clause can only affect the program if it is a dynamic replacement candidate. I had assumed this is referring to the runtime behavior of the program, and not (for instance) whether a compiler error is emitted due to a failing static assert.

Also, in order to determine what are the dynamic replacement candidates, and their order, all specified score expressions would need to be evaluated. Then, you'd need to evaluate the static context selectors, in decreasing order of their score, to find which one is the last dynamic replacement candidate. So I think template instantiations could be possible for those expressions, even if the corresponding variants aren't selected?

clang/include/clang/AST/StmtOpenMP.h

610

r

[jdoerfert]

In D91944#2457744, @dreachem wrote:

In D91944#2414364, @jdoerfert wrote:

This looks close to an OpenMP 5.0 implementation. I left comments inlined.

We need tests that show how non-selected alternatives *do not* impact the program. As an example, a template instantiation inside of a non-selected alternative is not actually performed.

We also need test with ill-formed metadirectives.

@jdoerfert I'm still trying to understand this thing regarding template instantiations.

The problem is this patch can only resolve to a single directive during parsing. Take

template<bool b>
void foo() {
  #pragma omp metadirective when(user={condition(b)}) ...
}

which is not resolvable at parsing time but it is a valid OpenMP 5.0 use of the metadirective
that needs to resolve at compile time.

The spec says that a directive variant associated with a when clause can only affect the program if it is a dynamic replacement candidate. I had assumed this is referring to the runtime behavior of the program, and not (for instance) whether a compiler error is emitted due to a failing static assert.

I always assume(d) that static_assert is something "affecting the program". It doesn't matter though because if you instantiate all the clauses eagerly you change things for the runtime as well, e.g., you can cause different template instances to be selected later on depending on earlier instantiations. So it's not "just" static_assert.

Also, in order to determine what are the dynamic replacement candidates, and their order, all specified score expressions would need to be evaluated. Then, you'd need to evaluate the static context selectors, in decreasing order of their score, to find which one is the last dynamic replacement candidate. So I think template instantiations could be possible for those expressions, even if the corresponding variants aren't selected?

Yes, we will always evaluate selectors and scores. The key is that we won't evaluate the directive variant, which is neither a selector nor a score.

I hope this makes sense.

[jdoerfert]

As discussed in the OpenMP in LLVM call on December 9th, we should go ahead with this patch and add support for the missing features, e.g., dependent selectors, afterwards. LGTM

[jdoerfert]

(Please make sure all clang and clang-tidy tests pass properly so we can merge the patch)

[ABataev]

clang/lib/Sema/TreeTransform.h

8519–8524

It would not work correctly, I would replace it with just error emission that instantiation is not supported yet.

[alokmishra.besu]

All clang test and clang-tidy pass. Ran clang-format on all code, except clang/include/clang/Serialization/ASTBitCodes.h which was formatting unrelated code as well.

[alokmishra.besu]

Emitting error instead of instantiation in clang/lib/Sema/TreeTransform.h. Added a TODO for future.

[alokmishra.besu]

Rebased with current branch to avoid patch failure

[cchen]

@alokmishra.besu, I'm trying to play/learn with your patch so I downloaded the diff and apply it to the master branch, however, I'm getting error messages everywhere if llvm::omp::OMPD_metadirective appears:

llvm-project/clang/include/clang/AST/StmtOpenMP.h:384:43: error: no member named 'OMPD_metadirective' in namespace 'llvm::omp'
                               llvm::omp::OMPD_metadirective, SourceLocation(),
                               ~~~~~~~~~~~^

Do you know why this is happening? (I've also tried clean build it but still get the error msg) Thanks!

Edit: I've been successfully compiled it after changing a computer, thanks.

[jdoerfert]

Are the test all passing?

[protze.joachim]

I found two issues with this patch regarding the default clause:

• The spec does not require a default clause. I get error: expected expression if I omit a default clause. The error is gone if I add default().
• The spec does not allow an empty default() clause, but rather expects default(nothing)or omission of the default clause. This patch accepts the empty default clause.

[jdoerfert]

In D91944#2504924, @protze.joachim wrote:

I found two issues with this patch regarding the default clause:

• The spec does not require a default clause. I get error: expected expression if I omit a default clause. The error is gone if I add default().
• The spec does not allow an empty default() clause, but rather expects default(nothing)or omission of the default clause. This patch accepts the empty default clause.

There are various issues with this patch. We will fix them afterwards. The patch provides a lot of infrastructure we need. Please provide the problematic cases in a bug.

[jdoerfert]

In D91944#2485167, @jdoerfert wrote:

Are the test all passing?

Can we fix the failing tests so we can merge this?

[alokmishra.besu]

In D91944#2505159, @jdoerfert wrote:

In D91944#2485167, @jdoerfert wrote:

Are the test all passing?

Can we fix the failing tests so we can merge this?

I will work on it this week. Will update soon.

[alokmishra.besu]

I've rebase this patch with the latest git code.
All test cases pass.
I've also applied this patch to a new git clone. It applies and builds successfully.

[jdoerfert]

There are no test cases anymore, as far as I can tell.

[alokmishra.besu]

In D91944#2540178, @jdoerfert wrote:

There are no test cases anymore, as far as I can tell.

Updated patch.

[jdoerfert]

Asssuming this passes the tests I'll merge it as is. There are unresolved review requests, e.g., custom implementation instead of balanced parenthesis trackers, the template support, etc.
but we decided we can make faster progress in tree once this is merged.

[protze.joachim]

In D91944#2458154, @jdoerfert wrote:

The problem is this patch can only resolve to a single directive during parsing. Take

template<bool b>
void foo() {
  #pragma omp metadirective when(user={condition(b)}) ...
}

which is not resolvable at parsing time but it is a valid OpenMP 5.0 use of the metadirective
that needs to resolve at compile time.

It's unfortunate that this pattern is not supported by this patch. How difficult would it be to provide this support, or would the implementation be not different to dynamic conditions?
For this templated pattern, the optimizer would throw away the branch.

[cchen]

I'm guessing the tests were not pass on buildbot but passed on the author's side is due to the assertion was disabled on the author's side.
Here is the patch for avoiding all the assertion errors and I'm able to get all the metadirective tests passed (and no regression for the existing omp tests) with this change:

diff --git a/clang/lib/Parse/ParseOpenMP.cpp b/clang/lib/Parse/ParseOpenMP.cpp
index 5ac6dd0fb55a..3313efe524f3 100644
--- a/clang/lib/Parse/ParseOpenMP.cpp
+++ b/clang/lib/Parse/ParseOpenMP.cpp
@@ -2277,8 +2277,10 @@ Parser::DeclGroupPtrTy Parser::ParseOpenMPDeclarativeDirectiveWithExtDecl(
 ///
 StmtResult
 Parser::ParseOpenMPDeclarativeOrExecutableDirective(ParsedStmtContext StmtCtx) {
-  assert(Tok.is(tok::annot_pragma_openmp) && "Not an OpenMP directive!");
   static bool ReadDirectiveWithinMetadirective = false;
+  if (!ReadDirectiveWithinMetadirective)
+    assert(Tok.isOneOf(tok::annot_pragma_openmp, tok::annot_attr_openmp) &&
+           "Not an OpenMP directive!");
   ParsingOpenMPDirectiveRAII DirScope(*this);
   ParenBraceBracketBalancer BalancerRAIIObj(*this);
   SmallVector<OMPClause *, 5> Clauses;
@@ -2288,7 +2290,7 @@ Parser::ParseOpenMPDeclarativeOrExecutableDirective(ParsedStmtContext StmtCtx) {
   unsigned ScopeFlags = Scope::FnScope | Scope::DeclScope |
                         Scope::CompoundStmtScope | Scope::OpenMPDirectiveScope;
   if (!ReadDirectiveWithinMetadirective)
-      ConsumeAnnotationToken();
+    ConsumeAnnotationToken();
   SourceLocation Loc = Tok.getLocation(), EndLoc;
   OpenMPDirectiveKind DKind = parseOpenMPDirectiveKind(*this);
   if (ReadDirectiveWithinMetadirective && DKind == OMPD_unknown) {
@@ -2331,6 +2333,7 @@ Parser::ParseOpenMPDeclarativeOrExecutableDirective(ParsedStmtContext StmtCtx) {
         parseOMPContextSelectors(Loc, TI);
         if (TI.Sets.size() == 0) {
           Diag(Tok, diag::err_omp_expected_context_selector) << "when clause";
+          TPA.Commit();
           return Directive;
         }

@@ -2339,6 +2342,7 @@ Parser::ParseOpenMPDeclarativeOrExecutableDirective(ParsedStmtContext StmtCtx) {
           ConsumeAnyToken();
         else {
           Diag(Tok, diag::err_omp_expected_colon) << "when clause";
+          TPA.Commit();
           return Directive;
         }
       }
@@ -2352,6 +2356,8 @@ Parser::ParseOpenMPDeclarativeOrExecutableDirective(ParsedStmtContext StmtCtx) {
         if (Tok.is(tok::annot_pragma_openmp_end)) {
           Diag(Tok, diag::err_omp_expected_punc)
               << getOpenMPClauseName(CKind) << 0;
+          TPA.Commit();
           return Directive;
         }
         ConsumeAnyToken();
@@ -2627,7 +2633,7 @@ Parser::ParseOpenMPDeclarativeOrExecutableDirective(ParsedStmtContext StmtCtx) {
       // ends with a ')'.
       if (ReadDirectiveWithinMetadirective && Tok.is(tok::r_paren)) {
         while (Tok.isNot(tok::annot_pragma_openmp_end))
-          ConsumeToken();
+          ConsumeAnyToken();
         break;
       }
       bool HasImplicitClause = false;

[cchen]

@alokmishra.besu do you mind if I push the patch for solving those assertions with rebase? The patch does not change the logic in your program and I've made sure that the tests could pass in debug mode.

[alokmishra.besu]

In D91944#2990234, @cchen wrote:

@alokmishra.besu do you mind if I push the patch for solving those assertions with rebase? The patch does not change the logic in your program and I've made sure that the tests could pass in debug mode.

I think your patch is valid. Thanks for it. Please go ahead.

[cchen]

Rebase and avoid assert errors

[cchen]

Remove redundant file

[cchen]

Remove debug info and spaces

[cchen]

Fix ast errors and add some tiny fixes

[cchen]

Rebase and fix warning

[cchen]

Fix flang issue

[cchen]

Fix tests for Windows

[ABataev]

clang/include/clang/AST/StmtOpenMP.h

5412

1. Make it private, please
2. Var names must start from capital letter stmt->S

clang/lib/Parse/ParseOpenMP.cpp

2389

Please, fix var names.

[cchen]

clang/include/clang/AST/StmtOpenMP.h

5412

I'm going to fix it. By the way, do you know how to fix those failing Windows tests? I tried to fix it by adding ifndef HEADER to test files and also replace var names with regex, but those Windows tests still fail. Thanks

[ABataev]

clang/include/clang/AST/StmtOpenMP.h

5412

No idea. Need a bit of context (I mean, would be good to see the test log etc.).

[cchen]

clang/include/clang/AST/StmtOpenMP.h

5412

I think the run line might be so general, I update it and see if that helps.

[ABataev]

clang/include/clang/AST/StmtOpenMP.h

5412

Just provide target triple in all test runs commands for linux and make a separate test for windows (if required), it should fix the issue with the testing.

[cchen]

Fix tests and coding style

[cchen]

I reapplied the patch since I forgot to add author's name in the commit

[phosek]

We started seeing a test failure in Clang :: OpenMP/metadirective_device_kind_codegen.c on our macOS bot after this change landed (we aren't seeing it on other systems):

Script:
--
: 'RUN: at line 1';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -cc1 -internal-isystem /opt/s/w/ir/x/w/staging/llvm_build/lib/clang/14.0.0/include -nostdsysteminc -verify -fopenmp -x c -std=c99 -emit-llvm /opt/s/w/ir/x/w/llvm-project/clang/test/OpenMP/metadirective_device_kind_codegen.c -o - | /opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck --allow-unused-prefixes /opt/s/w/ir/x/w/llvm-project/clang/test/OpenMP/metadirective_device_kind_codegen.c
: 'RUN: at line 2';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -cc1 -internal-isystem /opt/s/w/ir/x/w/staging/llvm_build/lib/clang/14.0.0/include -nostdsysteminc -verify -fopenmp -x c -triple x86_64-unknown-linux -emit-llvm /opt/s/w/ir/x/w/llvm-project/clang/test/OpenMP/metadirective_device_kind_codegen.c -o - | /opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck --allow-unused-prefixes /opt/s/w/ir/x/w/llvm-project/clang/test/OpenMP/metadirective_device_kind_codegen.c
: 'RUN: at line 3';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -cc1 -internal-isystem /opt/s/w/ir/x/w/staging/llvm_build/lib/clang/14.0.0/include -nostdsysteminc -verify -fopenmp -x c -triple aarch64-unknown-linux -emit-llvm /opt/s/w/ir/x/w/llvm-project/clang/test/OpenMP/metadirective_device_kind_codegen.c -o - | /opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck --allow-unused-prefixes /opt/s/w/ir/x/w/llvm-project/clang/test/OpenMP/metadirective_device_kind_codegen.c
: 'RUN: at line 4';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -cc1 -internal-isystem /opt/s/w/ir/x/w/staging/llvm_build/lib/clang/14.0.0/include -nostdsysteminc -verify -fopenmp -x c -triple ppc64le-unknown-linux -emit-llvm /opt/s/w/ir/x/w/llvm-project/clang/test/OpenMP/metadirective_device_kind_codegen.c -o - | /opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck --allow-unused-prefixes /opt/s/w/ir/x/w/llvm-project/clang/test/OpenMP/metadirective_device_kind_codegen.c
--
Exit Code: 1

Command Output (stderr):
--
/opt/s/w/ir/x/w/llvm-project/clang/test/OpenMP/metadirective_device_kind_codegen.c:39:17: error: CHECK-LABEL: expected string not found in input
// CHECK-LABEL: define {{.+}} void @foo()
                ^
<stdin>:1:1: note: scanning from here
; ModuleID = '/opt/s/w/ir/x/w/llvm-project/clang/test/OpenMP/metadirective_device_kind_codegen.c'
^
<stdin>:13:1: note: possible intended match here
define void @foo() #0 {
^

Input file: <stdin>
Check file: /opt/s/w/ir/x/w/llvm-project/clang/test/OpenMP/metadirective_device_kind_codegen.c

-dump-input=help explains the following input dump.

Input was:
<<<<<<
            1: ; ModuleID = '/opt/s/w/ir/x/w/llvm-project/clang/test/OpenMP/metadirective_device_kind_codegen.c' 
label:39'0     X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
            2: source_filename = "/opt/s/w/ir/x/w/llvm-project/clang/test/OpenMP/metadirective_device_kind_codegen.c" 
label:39'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            3: target datalayout = "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128" 
label:39'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            4: target triple = "x86_64-apple-darwin19.6.0" 
label:39'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            5:  
label:39'0     ~
            6: %struct.ident_t = type { i32, i32, i32, i32, i8* } 
label:39'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            7:  
label:39'0     ~
            8: @0 = private unnamed_addr constant [23 x i8] c";unknown;unknown;0;0;;\00", align 1 
label:39'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            9: @1 = private unnamed_addr constant %struct.ident_t { i32 0, i32 2, i32 0, i32 0, i8* getelementptr inbounds ([23 x i8], [23 x i8]* @0, i32 0, i32 0) }, align 8 
label:39'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           10: @2 = private unnamed_addr constant %struct.ident_t { i32 0, i32 514, i32 0, i32 0, i8* getelementptr inbounds ([23 x i8], [23 x i8]* @0, i32 0, i32 0) }, align 8 
label:39'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           11:  
label:39'0     ~
           12: ; Function Attrs: noinline nounwind optnone 
label:39'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           13: define void @foo() #0 { 
label:39'0     ~~~~~~~~~~~~~~~~~~~~~~~~
label:39'1     ?                        possible intended match
           14: entry: 
label:39'0     ~~~~~~~
           15:  %0 = call i32 @__kmpc_global_thread_num(%struct.ident_t* @1) 
label:39'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           16:  call void (%struct.ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_call(%struct.ident_t* @1, i32 0, void (i32*, i32*, ...)* bitcast (void (i32*, i32*)* @.omp_outlined. to void (i32*, i32*, ...)*)) 
label:39'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           17:  call void @__kmpc_push_num_threads(%struct.ident_t* @1, i32 %0, i32 4) 
label:39'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           18:  call void (%struct.ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_call(%struct.ident_t* @1, i32 0, void (i32*, i32*, ...)* bitcast (void (i32*, i32*)* @.omp_outlined..1 to void (i32*, i32*, ...)*)) 
label:39'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            .
            .
            .
>>>>>>

--

Would it be possible to take a look and either quickly address the issue or revert the change?

[• thakis]

(Reverted for now since mac bots have been broken for 16 hours now.)

[davezarzycki]

Also, when this lands again, please ensure that all the tests don't accidentally dump build artifacts into the source directory. Specifically, the following test was missing -o -: clang/test/OpenMP/metadirective_messages.cpp

[uweigand]

Looks like this was committed again, breaking the SystemZ build bots once again:
https://lab.llvm.org/buildbot/#/builders/94/builds/5661

[cchen]

In D91944#3009003, @uweigand wrote:

Looks like this was committed again, breaking the SystemZ build bots once again:
https://lab.llvm.org/buildbot/#/builders/94/builds/5661

I'm going to fix this issue now.

[cchen]

The SystemZ issue is due to the fact that we assumed that device(cpu) should be evaluated to true and device(gpu) should be evaluated to false in the test so the test should be fixed by specifying the triple. (https://github.com/llvm/llvm-project/commit/3679d2001c87f37101e7f20c646b21e97d8a0867)

[uweigand]

In D91944#3009868, @cchen wrote:

The SystemZ issue is due to the fact that we assumed that device(cpu) should be evaluated to true and device(gpu) should be evaluated to false in the test so the test should be fixed by specifying the triple. (https://github.com/llvm/llvm-project/commit/3679d2001c87f37101e7f20c646b21e97d8a0867)

Thanks, it looks like this fixed the problem.