Skip to content

[Flang][OpenMP] Fix allocating arrays with size intrinisic #225

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 9, 2024

Conversation

agozillon
Copy link

Attempt to address the following example from causing an assert or ICE:

subroutine test(a)
implicit none
integer :: i
real(kind=real64), dimension(:) :: a
real(kind=real64), dimension(size(a, 1)) :: b

!$omp target map(tofrom: b)
do i = 1, 10
b(i) = i
end do
!$omp end target
end subroutine

Where we utilise a Fortran intrinsic (size) to calculate the size of allocatable arrays and then map it to device.

Borrowing some of Kareem Ergawy's current work to disentangle bounds generation from the semantic/PFT information.

Co-author: Kareem Ergawy : kareem.ergawy@amd.com

Comment on lines 612 to 615
inline AddrAndBoundsInfo getDataOperandBaseAddr(fir::FirOpBuilder &builder,
mlir::Value symAddr,
bool isOptional,
mlir::Location loc) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spurious change of formatting. Please undo.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you will address that in an update in a little bit!

Comment on lines +1320 to +1322
// which comes with a fairly large overhead comparatively. We could be
// more robust about this and check using a BackWardsSlice to see if we
// run the risk of mapping a box.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this warrant an assert or something to make this explicitly visible should a code cause this to happen?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a bit hesitant to add an assert, as it isn't an issue of correctness (at least it shouldn't be now after this patch and some testing), as it will work, it's just a bit more of an egregious copy now than it was before as the mappings gotten a little more complicated, so avoiding where possible is nice. Basically don't want to assert for perfectly valid and working code! It would be nice to be able to add performance warnings for these kinds of cases as opposed to flat ICEs/asserts, but I don't think flang has infrastructure for this sadly

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I'm fine with that.

Copy link

@mjklemm mjklemm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Attempt to address the following example from causing an assert or ICE:

   subroutine test(a)
        implicit none
        integer :: i
        real(kind=real64), dimension(:) :: a
        real(kind=real64), dimension(size(a, 1)) :: b

!$omp target map(tofrom: b)
        do i = 1, 10
            b(i) = i
        end do
!$omp end target
end subroutine

Where we utilise a Fortran intrinsic (size) to calculate the size of allocatable arrays and then map it to device.

Borrowing some of Kareem Ergawy's current work to disentangle bounds generation from the semantic/PFT information.

Co-author: Kareem Ergawy : kareem.ergawy@amd.com
@agozillon agozillon merged commit 73deda0 into ROCm:amd-trunk-dev Dec 9, 2024
2 of 4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants