This is an archive of the discontinued LLVM Phabricator instance.

[MLIR][OpenMP] Fix compiler crash when translating omp.target to LLVM IR
ClosedPublic

Authored by skatrak on Aug 24 2023, 3:45 AM.

Details

Summary

This patch fixes a compiler crash that would happen during translation to LLVM IR if the optional map argument of the omp.target operation was not present. A unit test is added to ensure this has been fixed.

Diff Detail

Event Timeline

skatrak created this revision.Aug 24 2023, 3:45 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 24 2023, 3:46 AM
skatrak requested review of this revision.Aug 24 2023, 3:46 AM
agozillon accepted this revision.EditedAug 24 2023, 9:31 AM

LGTM, nice catch! My patch series changes the way map is accessed soon but it'll take a while to land I imagine. However, in the meantime perhaps there are other operations that suffer similarly at the moment, like the enter/exit data operations, I believe they use getMapType as well currently, but I don't know if they access the getMapType information in the same way (or if they can be tested in the same way, I don't know how/if they lower fully to LLVM-IR at the moment, I'm unfamiliar with them outside of knowing they have map information that needs processed).

This revision is now accepted and ready to land.Aug 24 2023, 9:31 AM

LGTM, nice catch! My patch series changes the way map is accessed soon but it'll take a while to land I imagine. However, in the meantime perhaps there are other operations that suffer similarly at the moment, like the enter/exit data operations, I believe they use getMapType as well currently, but I don't know if they access the getMapType information in the same way (or if they can be tested in the same way, I don't know how/if they lower fully to LLVM-IR at the moment, I'm unfamiliar with them outside of knowing they have map information that needs processed).

Thank you Andrew for looking at this. As far as I can see, the only ops for which the map_types argument is optional are omp.target_data and omp.target, and for omp.target_data the result of getMapTypes() is always checked to exist before using it. For omp.target_{enter|exit}_data the argument is required, so using the result of getMapTypes() is not going to crash the compiler there. I believe this small patch is the only place that we missed that check.

I'll wait until Monday to land this patch, in case someone else has any comments before accepting it.

LGTM, nice catch! My patch series changes the way map is accessed soon but it'll take a while to land I imagine. However, in the meantime perhaps there are other operations that suffer similarly at the moment, like the enter/exit data operations, I believe they use getMapType as well currently, but I don't know if they access the getMapType information in the same way (or if they can be tested in the same way, I don't know how/if they lower fully to LLVM-IR at the moment, I'm unfamiliar with them outside of knowing they have map information that needs processed).

Thank you Andrew for looking at this. As far as I can see, the only ops for which the map_types argument is optional are omp.target_data and omp.target, and for omp.target_data the result of getMapTypes() is always checked to exist before using it. For omp.target_{enter|exit}_data the argument is required, so using the result of getMapTypes() is not going to crash the compiler there. I believe this small patch is the only place that we missed that check.

I'll wait until Monday to land this patch, in case someone else has any comments before accepting it.

Sounds good! Thank you for looking into it further.