This is an archive of the discontinued LLVM Phabricator instance.

[mlir][OpenMP] Add support for using Opaque Pointers in the OpenMP Dialect
ClosedPublic

Authored by zero9178 on Feb 8 2023, 6:33 AM.

Details

Summary

The current OpenMP implementation assumes the use of typed pointers (or rather typed pointer like types). Given the support for typed pointers in LLVM is now pending removal, the OpenMP Dialect should be able to support opaque pointers as well, given that any users of it must lower OpenMP through the LLVM Dialect.

This patch fixes the above and adds support for using LLVM opaque pointers with the OpenMP dialect. This is implemented by making all related code not make use of the element type of pointer arguments. The few (one) op requiring a pointer element type now use an explicit TypeAttr for representing the element type.
More concretely, the list of changes are:

  • omp.atomic.read now has an extra TypeAttr (also in syntax) which is the element type of the values read and stored from the operands
  • omp.reduction now has an type argument in the syntax for both the accmulator and operand since the operand type can no longer be inferred from the accumulator
  • OpenMPToLLVMIRTranslation.cpp was rewritten to never query element types of pointers
  • Adjusted the verifier to be able to handle pointers without element types

Note on the last point: I opted to keep OpenMP_PointerLikeTypeInterface as it is useful for the verification of existing typed pointer code. It does not really have use for any other purpose however and one may consider replacing its use as type constraint with AnyType. I have not done so yet.

Diff Detail

Event Timeline

zero9178 created this revision.Feb 8 2023, 6:33 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
zero9178 requested review of this revision.Feb 8 2023, 6:33 AM
gysit added inline comments.Feb 9 2023, 12:59 AM
mlir/test/Target/LLVMIR/openmp-reduction.mlir
32

Would it make sense to change all the tests in openmp-reduction.mlir to opaque pointers and keep the simple_reduction test as a typed pointer test in a separate typed pointer test file?

491

nit: don't forget the missing newline here.

Thanks @zero9178 for this patch. I have not been fully following the opaque pointer changes, so I am not fully familiar with them. I see that tests retain types like !llvm.ptr<f32> which implicitly means that there is an ElementType of Type f32. So what is exactly the change that is being made in the LLVM MLIR dialect?

The OpenMP_PointerLikeType has been a useful mechanism to enforce some restrictions on the types that can be used as operands in places where we expect a variable-like entity. Many of the higher-level dialects have the getElementType function. It would be great to retain it. Could you suggest alternatives if this is not possible now?

zero9178 added a comment.EditedFeb 9 2023, 4:34 AM

Thanks @zero9178 for this patch. I have not been fully following the opaque pointer changes, so I am not fully familiar with them. I see that tests retain types like !llvm.ptr<f32> which implicitly means that there is an ElementType of Type f32. So what is exactly the change that is being made in the LLVM MLIR dialect?

The LLVM MLIR dialect, just like normal LLVM, is essentially getting rid of the element types of pointers entirely. This has been a migration going on within actual LLVM IR for a few years now and with the bump to LLVM 17, typed pointers in LLVM IR are now officially unsupported. As part of https://discourse.llvm.org/t/rfc-switching-the-llvm-dialect-and-dialect-lowerings-to-opaque-pointers/68179 I am now trying to convert all of MLIR to be compatible with opaque pointers (so that downstream have the opportunity to switch) followed by then at a later time, removing typed pointers entirely in LLVM MLIR dialect. Removing typed pointer support would remove maintainence burden in the LLVM MLIR Dialect and ensure it is up to sync with actual LLVM IR in the future. For the motivation of why opaque pointers are a thing see [0] and [1].

The current status is that I'm adding flags to conversion passes to support emitting LLVM IR with opaque pointers. The OpenMP dialect did not yet support the use of opaque pointers within its ops, due to the implicit assumption that getElementType always returns a type. This patch essentially fixes that issue.

As to the tests: I did not plan to switch all the tests to opaque pointers yet in this commit although I'd be happy to do so. I'd also retain some tests with typed pointers as a regression test. Otherwise I'd have done so in a separate review.

The OpenMP_PointerLikeType has been a useful mechanism to enforce some restrictions on the types that can be used as operands in places where we expect a variable-like entity. Many of the higher-level dialects have the getElementType function. It would be great to retain it. Could you suggest alternatives if this is not possible now?

I don't see any issues with keeping it, as long as people are aware that its getElementType method may return nullptr. Its only use currently and after this patch is in verification where if the returned element type is not a nullptr, it is used to check for consistency of types elsewhere in the ops. That way you keep all the benefits you currently have.

[0] https://llvm.org/docs/OpaquePointers.html
[1] https://www.npopov.com/2021/06/02/Design-issues-in-LLVM-IR.html#pointer-element-types

LGTM. Thanks @zero9178 for this change and the discussion.

This revision is now accepted and ready to land.Feb 10 2023, 5:38 AM
zero9178 updated this revision to Diff 496494.Feb 10 2023, 8:43 AM
zero9178 marked an inline comment as done.

Address review comments:

  • switch reduction export tests to opaque pointers and keep typed pointer tests in a separate file
This revision was landed with ongoing or failed builds.Feb 10 2023, 8:56 AM
This revision was automatically updated to reflect the committed changes.