This is an archive of the discontinued LLVM Phabricator instance.

[flang][OpenMP] Fix firstprivate bug
ClosedPublic

Authored by arnamoy10 on Jun 6 2022, 11:28 AM.

Details

Summary

In case where the bound(s) of a workshare loop use(s) firstprivate var(s), currently, that use is not updated with the created clone. It still uses the shared variable. This patch fixes that.

Diff Detail

Event Timeline

arnamoy10 created this revision.Jun 6 2022, 11:28 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptJun 6 2022, 11:28 AM
arnamoy10 requested review of this revision.Jun 6 2022, 11:28 AM

Not requesting a change: But have you considered performing privatisation before creating the loop bounds for the worksharing loop?

flang/lib/Lower/Bridge.cpp
515–521

There are functions called replaceAllUsesWith. Are they not sufficient for the purpose here?

peixin added a comment.Jun 8 2022, 2:38 AM

Not requesting a change: But have you considered performing privatisation before creating the loop bounds for the worksharing loop?

+1 It's better to use copyHostAssociateVar unconditionally for all the cases and handle special usage elsewhere.

But have you considered performing privatisation before creating the loop bounds for the worksharing loop?

Earlier, I thought about doing it this way but realized that privatization is tied to body creation and both run in a single call to createBodyOfOp. Separating them would require a little more change to the IR but I think that would be a step in the right direction. If we carefully separate privatization from body creation, then we will automatically handle this bug.

peixin added a comment.EditedJun 9 2022, 8:05 PM

But have you considered performing privatisation before creating the loop bounds for the worksharing loop?

Earlier, I thought about doing it this way but realized that privatization is tied to body creation and both run in a single call to createBodyOfOp. Separating them would require a little more change to the IR but I think that would be a step in the right direction. If we carefully separate privatization from body creation, then we will automatically handle this bug.

I think the problem is not if the privatization is tied to the body creation or not. The problem is getting the loop bounds values in worksharing-loop use the value of the host symbol instead of the associated symbol. There should be no problem with privatisation. For example, the lowering of copyin clause (D127468) does not have this problem since I explicitly use the host and associated symbols for both threadprivate and copyin variables.

flang/lib/Lower/Bridge.cpp
515–521

If you want to do this here. Please make sure it won't crash the usage of this function elsewhere such as lowering for copyin clause D127468.

Rebasing. Also did not attempt to move this before loop-bounds creation (will not be a simple fix IMHO), adding a TODO

peixin added inline comments.Jul 3 2022, 8:01 PM
flang/lib/Lower/Bridge.cpp
475

Can you fix the comment to describe that this is esepcially for loop bounds since loop bounds used old values which need to be fixed by using the new copied value?

478

Remove the TODO. The code cannot be moved there.

483
arnamoy10 updated this revision to Diff 443500.Jul 10 2022, 6:20 AM

Rebase, update comment and code to reflect reviewer's comments.

peixin accepted this revision.Jul 11 2022, 12:27 AM

LGTM

This revision is now accepted and ready to land.Jul 11 2022, 12:27 AM
This revision was automatically updated to reflect the committed changes.
flang/lib/Lower/Bridge.cpp
478

Can we add a TODO to call privatization before the loop operation is created as a directly submitted NFC patch?