Page MenuHomePhabricator

[Flang][OpenMP 4.5] Add semantic check for OpenMP Do Loop Constructs for Threadprivate
ClosedPublic

Authored by yhegde on Feb 14 2021, 11:10 PM.

Details

Summary

Semantic check for OpenMP 4.5 - 2.7.1 Do Loop restrictions for Threadprivate.
Implementation of Do loop threadprivate check.

This PR is created based on the review comments on the review PR https://reviews.llvm.org/D92732

File:
resolve-directives.cpp

Tescases:
omp-do04.f90
omp-do04-positivecase.f90

Diff Detail

Event Timeline

yhegde created this revision.Feb 14 2021, 11:10 PM
yhegde requested review of this revision.Feb 14 2021, 11:10 PM

@kiranchandramohan , I was working with the following test case you have given ,

module md
integer :: i
!$omp threadprivate(i)
end module

program mn
use md
!$omp do
do i = 1, 10

do j = 1, 10
  print *, "Hello"
end do

end do
!$omp end do
end program
+++++++++++++++++++++++++++

The threadPrivateSymbol will get reset once the subroutine called up and it is set as OmpPredetermined and OmpPrivate and adjusted with in the DO loop region and it seems calling DeclareOrMarkOtherAccessEntity to set the Symbol flag to OmpThreadprivate and I think MakeAssocSymbol called with OmpPrivate to create HostAssocDetails. Then I am getting the symbol from HostAssocDtails and then checking whether it is OmpThreadprivate . Its working and throwing the following err.

./tpmodule.f90:9:4: error: Loop iteration variable i is not allowed in THREADPRIVATE.

do i = 1, 10 
   ^

if this is the case , I suppose no where I need to call ClearThreadPrivateSymbols() because all the symbols in the threadPrivateSymbols are reset and new symbols get generated ( local copies probably ). Do you think I am missing anything ? Is this ok ? Please let me know. Thank you.

@kiranchandramohan , I was working with the following test case you have given ,

module md
integer :: i
!$omp threadprivate(i)
end module

program mn
use md
!$omp do
do i = 1, 10

do j = 1, 10
  print *, "Hello"
end do

end do
!$omp end do
end program
+++++++++++++++++++++++++++

The threadPrivateSymbol will get reset once the subroutine called up and it is set as OmpPredetermined and OmpPrivate and adjusted with in the DO loop region and it seems calling DeclareOrMarkOtherAccessEntity to set the Symbol flag to OmpThreadprivate and I think MakeAssocSymbol called with OmpPrivate to create HostAssocDetails. Then I am getting the symbol from HostAssocDtails and then checking whether it is OmpThreadprivate . Its working and throwing the following err.

./tpmodule.f90:9:4: error: Loop iteration variable i is not allowed in THREADPRIVATE.

do i = 1, 10 
   ^

if this is the case , I suppose no where I need to call ClearThreadPrivateSymbols() because all the symbols in the threadPrivateSymbols are reset and new symbols get generated ( local copies probably ). Do you think I am missing anything ? Is this ok ? Please let me know. Thank you.

But this code does not work if module.f90 contains
module md
integer :: i
!$omp threadprivate(i)
end module

and tp.f90 uses that module - like
program mn
use md
!$omp do
do i = 1, 10

do j = 1, 10
  print *, "Hello"
end do

end do
!$omp end do
end program

But gfortran gives error.

It works for the following case.

module tp

integer i
!$omp threadprivate(i)

end module tp

module usetp

use tp

end module usetp

program main

use usetp

!$omp do
do i = 1, 10

do j = 1, 10
  print *, "Hello"
end do

end do
!$omp end do
end program

Error msg
./module.f90:14:4: error: Loop iteration variable i is not allowed in THREADPRIVATE.

do i = 1, 10
   ^
yhegde updated this revision to Diff 328791.Mar 6 2021, 11:29 AM

Patch updated and rebased to check Threadprivate variables in do loops , across the modules.

kiranchandramohan accepted this revision.Mar 7 2021, 4:08 PM

LGTM. Yes, using the symbol is the right way here.
Thanks @yhegde for separating this out into a new patch. Thanks also for you patience and all your work for semantic checks for OpenMP.

This revision is now accepted and ready to land.Mar 7 2021, 4:08 PM
yhegde added a comment.Mar 8 2021, 5:40 AM

LGTM. Yes, using the symbol is the right way here.
Thanks @yhegde for separating this out into a new patch. Thanks also for you patience and all your work for semantic checks for OpenMP.

Thank you @kiranchandramohan for the review comments. That was a good opportunity to understand flang and it was nice working with you.