This is an archive of the discontinued LLVM Phabricator instance.

[OPENMP]Fix PR45854: prevent code movement out of the critical region.
AbandonedPublic

Authored by ABataev on Jun 4 2020, 12:59 PM.

Details

Summary

Need to emit memory barriers upon enter/exit to/from critical region to
prevent code movement.

Diff Detail

Event Timeline

ABataev created this revision.Jun 4 2020, 12:59 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptJun 4 2020, 12:59 PM

Is it possible to have the same problem with other directives, like 'omp single' or 'omp master'? I haven't seen any test fail for those yet though.

llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
357

instructions

380

instructions

Is it possible to have the same problem with other directives, like 'omp single' or 'omp master'? I haven't seen any test fail for those yet though.

I rather doubt. The main problem with the critical directive that load/stores should not be moved out of the region (they all should be executed in the critical region context, just like atomics). For single and master it should be fine.

I doubt this is the right fix. I'll take a closer look.

I doubt this is the right fix. I'll take a closer look.

I believe, the issue is caused by the new attributes for kmpc_critical/kmpc_end_critical functions. They are marked as InaccessibleMemOrArgMemOnly functions. Previously they did not have this attribute and optimizer did not move the code across these function calls.

ABataev updated this revision to Diff 268592.Jun 4 2020, 2:28 PM

Rebase and fixes

I doubt this is the right fix. I'll take a closer look.

I believe, the issue is caused by the new attributes for kmpc_critical/kmpc_end_critical functions. They are marked as InaccessibleMemOrArgMemOnly functions. Previously they did not have this attribute and optimizer did not move the code across these function calls.

I would argue it is exposed not caused by the attribute ;)

See PR46210

ABataev abandoned this revision.Jun 4 2020, 5:23 PM

I doubt this is the right fix. I'll take a closer look.

I believe, the issue is caused by the new attributes for kmpc_critical/kmpc_end_critical functions. They are marked as InaccessibleMemOrArgMemOnly functions. Previously they did not have this attribute and optimizer did not move the code across these function calls.

I would argue it is exposed not caused by the attribute ;)

See PR46210

Agree, the attribute exposes the issue.