This is an archive of the discontinued LLVM Phabricator instance.

[OMPIRBuilder] Fix shared clause for task construct
ClosedPublic

Authored by psoni2628 on Aug 21 2023, 2:58 PM.

Details

Summary

This patch fixes the shared clause for the task construct with multiple shared variables. The shareds field in the kmp_task_t is not an inline array in the struct, rather it is a pointer to an array. With an inline array, the pointer dereference to the outlined function body of the task would segmentation fault when accessed by the runtime.

Diff Detail

Event Timeline

psoni2628 created this revision.Aug 21 2023, 2:58 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 21 2023, 2:58 PM
psoni2628 requested review of this revision.Aug 21 2023, 2:58 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptAug 21 2023, 2:58 PM

Thanks @psoni2628 for the patch. This is great.
Could you upload the patch with full context for ease of review?
Are the Clang OpenMP test failures related?

Thanks @psoni2628 for the patch. This is great.
Could you upload the patch with full context for ease of review?
Are the Clang OpenMP test failures related?

Yes. So for context, the following Fortran test case was failing previously, but now it runs.

subroutine foo()
  implicit none
  integer::x,y
  x=0
   !$omp task shared(x,y)
   x=2
   y=3

   !$omp end task
  !$omp taskwait        
  print *, x, y
end subroutine foo

program p
implicit none

!$omp parallel
!$omp single
call foo()
!$omp end single
!$omp end parallel
end program p

As for the clang failures, it looks like they are related. I think I just need to update the CHECK lines, but I'm still figuring that out.

Thanks @psoni2628 for the patch. This is great.
Could you upload the patch with full context for ease of review?
Are the Clang OpenMP test failures related?

Yes. So for context, the following Fortran test case was failing previously, but now it runs.

subroutine foo()
  implicit none
  integer::x,y
  x=0
   !$omp task shared(x,y)
   x=2
   y=3

   !$omp end task
  !$omp taskwait        
  print *, x, y
end subroutine foo

program p
implicit none

!$omp parallel
!$omp single
call foo()
!$omp end single
!$omp end parallel
end program p

As for the clang failures, it looks like they are related. I think I just need to update the CHECK lines, but I'm still figuring that out.

@psoni2628 By context, i meant showing the full diff for the files where changes are made.

To get a full diff, use one of the following commands (or just use Arcanist to upload your patch):

git show HEAD -U999999 > mypatch.patch
git diff -U999999 @{u} > mypatch.patch
git diff HEAD~1 -U999999 > mypatch.patch
psoni2628 updated this revision to Diff 552722.Aug 23 2023, 8:16 AM
  • Upload full diff

Thanks @psoni2628 for the patch. This is great.
Could you upload the patch with full context for ease of review?
Are the Clang OpenMP test failures related?

Yes. So for context, the following Fortran test case was failing previously, but now it runs.

subroutine foo()
  implicit none
  integer::x,y
  x=0
   !$omp task shared(x,y)
   x=2
   y=3

   !$omp end task
  !$omp taskwait        
  print *, x, y
end subroutine foo

program p
implicit none

!$omp parallel
!$omp single
call foo()
!$omp end single
!$omp end parallel
end program p

As for the clang failures, it looks like they are related. I think I just need to update the CHECK lines, but I'm still figuring that out.

Thanks @psoni2628 for the patch. This is great.
Could you upload the patch with full context for ease of review?
Are the Clang OpenMP test failures related?

Yes. So for context, the following Fortran test case was failing previously, but now it runs.

subroutine foo()
  implicit none
  integer::x,y
  x=0
   !$omp task shared(x,y)
   x=2
   y=3

   !$omp end task
  !$omp taskwait        
  print *, x, y
end subroutine foo

program p
implicit none

!$omp parallel
!$omp single
call foo()
!$omp end single
!$omp end parallel
end program p

As for the clang failures, it looks like they are related. I think I just need to update the CHECK lines, but I'm still figuring that out.

Thanks @psoni2628 for the patch. This is great.
Could you upload the patch with full context for ease of review?
Are the Clang OpenMP test failures related?

Yes. So for context, the following Fortran test case was failing previously, but now it runs.

subroutine foo()
  implicit none
  integer::x,y
  x=0
   !$omp task shared(x,y)
   x=2
   y=3

   !$omp end task
  !$omp taskwait        
  print *, x, y
end subroutine foo

program p
implicit none

!$omp parallel
!$omp single
call foo()
!$omp end single
!$omp end parallel
end program p

As for the clang failures, it looks like they are related. I think I just need to update the CHECK lines, but I'm still figuring that out.

@psoni2628 By context, i meant showing the full diff for the files where changes are made.

To get a full diff, use one of the following commands (or just use Arcanist to upload your patch):

git show HEAD -U999999 > mypatch.patch
git diff -U999999 @{u} > mypatch.patch
git diff HEAD~1 -U999999 > mypatch.patch

Done. I forgot to do that, sorry.

Thanks @psoni2628 for the patch. This is great.
Could you upload the patch with full context for ease of review?
Are the Clang OpenMP test failures related?

Yes. So for context, the following Fortran test case was failing previously, but now it runs.

subroutine foo()
  implicit none
  integer::x,y
  x=0
   !$omp task shared(x,y)
   x=2
   y=3

   !$omp end task
  !$omp taskwait        
  print *, x, y
end subroutine foo

program p
implicit none

!$omp parallel
!$omp single
call foo()
!$omp end single
!$omp end parallel
end program p

As for the clang failures, it looks like they are related. I think I just need to update the CHECK lines, but I'm still figuring that out.

The clang test failures are being caused by my addition of kmp_task_t to OMPKinds.def. It is conflicting with Clang's definition of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp, so the struct gets renamed to kmp_task_t.0 and kmp_task_t.1. I don't think it is that simple to update the usage of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp. Should I rename my addition of kmp_task_t in OMPKinds.def to kmp_task, or should I just fix the tests to allow kmp_task_t.0 and kmp_task_t.1?

Thanks @psoni2628 for the patch. This is great.
Could you upload the patch with full context for ease of review?
Are the Clang OpenMP test failures related?

Yes. So for context, the following Fortran test case was failing previously, but now it runs.

subroutine foo()
  implicit none
  integer::x,y
  x=0
   !$omp task shared(x,y)
   x=2
   y=3

   !$omp end task
  !$omp taskwait        
  print *, x, y
end subroutine foo

program p
implicit none

!$omp parallel
!$omp single
call foo()
!$omp end single
!$omp end parallel
end program p

As for the clang failures, it looks like they are related. I think I just need to update the CHECK lines, but I'm still figuring that out.

The clang test failures are being caused by my addition of kmp_task_t to OMPKinds.def. It is conflicting with Clang's definition of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp, so the struct gets renamed to kmp_task_t.0 and kmp_task_t.1. I don't think it is that simple to update the usage of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp. Should I rename my addition of kmp_task_t in OMPKinds.def to kmp_task, or should I just fix the tests to allow kmp_task_t.0 and kmp_task_t.1?

ping @jdoerfert

As for the clang failures, it looks like they are related. I think I just need to update the CHECK lines, but I'm still figuring that out.

The clang test failures are being caused by my addition of kmp_task_t to OMPKinds.def. It is conflicting with Clang's definition of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp, so the struct gets renamed to kmp_task_t.0 and kmp_task_t.1. I don't think it is that simple to update the usage of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp. Should I rename my addition of kmp_task_t in OMPKinds.def to kmp_task, or should I just fix the tests to allow kmp_task_t.0 and kmp_task_t.1?

Can we make use of the new kmp_task_t in Clang? That would be the correct way to resolve this.

As for the clang failures, it looks like they are related. I think I just need to update the CHECK lines, but I'm still figuring that out.

The clang test failures are being caused by my addition of kmp_task_t to OMPKinds.def. It is conflicting with Clang's definition of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp, so the struct gets renamed to kmp_task_t.0 and kmp_task_t.1. I don't think it is that simple to update the usage of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp. Should I rename my addition of kmp_task_t in OMPKinds.def to kmp_task, or should I just fix the tests to allow kmp_task_t.0 and kmp_task_t.1?

Can we make use of the new kmp_task_t in Clang? That would be the correct way to resolve this.

I am not sure how to go about doing that. I think the kmp_task_t struct is actually being created in llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:initializeTypes from the macro defined in OMPKinds.def. Do you know how I can refer to that struct in Clang?

As for the clang failures, it looks like they are related. I think I just need to update the CHECK lines, but I'm still figuring that out.

The clang test failures are being caused by my addition of kmp_task_t to OMPKinds.def. It is conflicting with Clang's definition of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp, so the struct gets renamed to kmp_task_t.0 and kmp_task_t.1. I don't think it is that simple to update the usage of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp. Should I rename my addition of kmp_task_t in OMPKinds.def to kmp_task, or should I just fix the tests to allow kmp_task_t.0 and kmp_task_t.1?

Can we make use of the new kmp_task_t in Clang? That would be the correct way to resolve this.

I am not sure how to go about doing that. I think the kmp_task_t struct is actually being created in llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:initializeTypes from the macro defined in OMPKinds.def. Do you know how I can refer to that struct in Clang?

I looked at this more closely, and I don't think it's possible to refer to kmp_task_t in Clang. The only way I can think of doing this is doing similarly to D123460, which is basically building the structure in OMPIRBuilder, and calling it in Clang. This is not a straightforward change to make though, because Clang builds several RecordDecls on top of kmp_task_t such as the taskloop_task and task_with_privates. We would also have to build those structs in OMPIRBuilder, but that expands the scope of this patch quite significantly. Is this what you meant @jdoerfert?

As for the clang failures, it looks like they are related. I think I just need to update the CHECK lines, but I'm still figuring that out.

The clang test failures are being caused by my addition of kmp_task_t to OMPKinds.def. It is conflicting with Clang's definition of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp, so the struct gets renamed to kmp_task_t.0 and kmp_task_t.1. I don't think it is that simple to update the usage of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp. Should I rename my addition of kmp_task_t in OMPKinds.def to kmp_task, or should I just fix the tests to allow kmp_task_t.0 and kmp_task_t.1?

Can we make use of the new kmp_task_t in Clang? That would be the correct way to resolve this.

I am not sure how to go about doing that. I think the kmp_task_t struct is actually being created in llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:initializeTypes from the macro defined in OMPKinds.def. Do you know how I can refer to that struct in Clang?

I looked at this more closely, and I don't think it's possible to refer to kmp_task_t in Clang. The only way I can think of doing this is doing similarly to D123460, which is basically building the structure in OMPIRBuilder, and calling it in Clang. This is not a straightforward change to make though, because Clang builds several RecordDecls on top of kmp_task_t such as the taskloop_task and task_with_privates. We would also have to build those structs in OMPIRBuilder, but that expands the scope of this patch quite significantly. Is this what you meant @jdoerfert?

I think we should proceed with either of the following two options:
-> Reuse Clang's kmp_task_t in the OpenMPIRBuilder and use only the relevant fields that we support now. I am assuming even if we have to move the definition of the Structure to OpenMPIRBuilder, there will not be much change in clang since the definition of the Structure remains the same. It is just a bit of additional logical to correctly dereference the portion of the structure in the OPenMPIRBuilder.
-> Define a separate kmp_task_ompbuilder_t and use that in the OpenMPIRBuilder.

As for the clang failures, it looks like they are related. I think I just need to update the CHECK lines, but I'm still figuring that out.

The clang test failures are being caused by my addition of kmp_task_t to OMPKinds.def. It is conflicting with Clang's definition of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp, so the struct gets renamed to kmp_task_t.0 and kmp_task_t.1. I don't think it is that simple to update the usage of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp. Should I rename my addition of kmp_task_t in OMPKinds.def to kmp_task, or should I just fix the tests to allow kmp_task_t.0 and kmp_task_t.1?

Can we make use of the new kmp_task_t in Clang? That would be the correct way to resolve this.

I am not sure how to go about doing that. I think the kmp_task_t struct is actually being created in llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:initializeTypes from the macro defined in OMPKinds.def. Do you know how I can refer to that struct in Clang?

I looked at this more closely, and I don't think it's possible to refer to kmp_task_t in Clang. The only way I can think of doing this is doing similarly to D123460, which is basically building the structure in OMPIRBuilder, and calling it in Clang. This is not a straightforward change to make though, because Clang builds several RecordDecls on top of kmp_task_t such as the taskloop_task and task_with_privates. We would also have to build those structs in OMPIRBuilder, but that expands the scope of this patch quite significantly. Is this what you meant @jdoerfert?

I think we should proceed with either of the following two options:
-> Reuse Clang's kmp_task_t in the OpenMPIRBuilder and use only the relevant fields that we support now. I am assuming even if we have to move the definition of the Structure to OpenMPIRBuilder, there will not be much change in clang since the definition of the Structure remains the same. It is just a bit of additional logical to correctly dereference the portion of the structure in the OPenMPIRBuilder.
-> Define a separate kmp_task_ompbuilder_t and use that in the OpenMPIRBuilder.

I don't think option 1 is possible. The struct gets created in https://github.com/llvm/llvm-project/blob/c987f9d7fdc7b22c9bf68d7b3f0df10b68c679be/llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp#L5680. IMO, the only way this makes sense is to create a function in OMPIRBuilder to populate the kmp_task_t, and then call that in Clang (similar to D123460). That is straightforward, but the issue is that we currently only populate the shareds field of kmp_task_t in OMPIRBuilder. We need to populate the other fields as well, otherwise we will lose the functionality in Clang. Once we have the full support for all the features of kmp_task_t in OMPIRBuilder, then we can use it. Until that happens we can just use a different struct name (i.e. the second option).

psoni2628 updated this revision to Diff 555208.Aug 31 2023, 5:37 PM
  • Change struct name to kmp_task_ompbuilder_t from kmp_task_t
jdoerfert added a comment.EditedAug 31 2023, 6:51 PM

As for the clang failures, it looks like they are related. I think I just need to update the CHECK lines, but I'm still figuring that out.

The clang test failures are being caused by my addition of kmp_task_t to OMPKinds.def. It is conflicting with Clang's definition of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp, so the struct gets renamed to kmp_task_t.0 and kmp_task_t.1. I don't think it is that simple to update the usage of kmp_task_t in clang/lib/CodeGen/CGOpenMPRuntime.cpp. Should I rename my addition of kmp_task_t in OMPKinds.def to kmp_task, or should I just fix the tests to allow kmp_task_t.0 and kmp_task_t.1?

Can we make use of the new kmp_task_t in Clang? That would be the correct way to resolve this.

I am not sure how to go about doing that. I think the kmp_task_t struct is actually being created in llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:initializeTypes from the macro defined in OMPKinds.def. Do you know how I can refer to that struct in Clang?

I looked at this more closely, and I don't think it's possible to refer to kmp_task_t in Clang. The only way I can think of doing this is doing similarly to D123460, which is basically building the structure in OMPIRBuilder, and calling it in Clang. This is not a straightforward change to make though, because Clang builds several RecordDecls on top of kmp_task_t such as the taskloop_task and task_with_privates. We would also have to build those structs in OMPIRBuilder, but that expands the scope of this patch quite significantly. Is this what you meant @jdoerfert?

Sorry for the delay. Yes, we should create all the structs in the OMPIRBuilder (or similar) and stop doing records in clang.
That said, I do not block this, but having two places creating "the same struct" is not a good idea and should be avoided as soon as possible.

kiranchandramohan accepted this revision.Sep 6 2023, 3:20 PM

LG.

@shraiysh You might not remember much of this. But would you have any comments here?

This revision is now accepted and ready to land.Sep 6 2023, 3:20 PM
This revision was automatically updated to reflect the committed changes.