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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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? |
+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.
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
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? |
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?