This is an archive of the discontinued LLVM Phabricator instance.

[Flang] Notify conversion failure for Proc ops, types
ClosedPublic

Authored by kiranchandramohan on Nov 15 2021, 3:33 AM.

Details

Summary

Add the FIR to LLVM conversion patterns for the BoxProcHostOp, EmboxProcOp, and UnboxProcOp ops and the boxproc type. These are currently unimplemented. Implementation will come at a later time when support for Fortran 2003 procedure pointer feature is added.

Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptNov 15 2021, 3:33 AM
Herald added a subscriber: mehdi_amini. · View Herald Transcript
kiranchandramohan requested review of this revision.Nov 15 2021, 3:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 15 2021, 3:33 AM
rovka added inline comments.Nov 15 2021, 4:06 AM
flang/test/Fir/types-to-llvm.fir
78 ↗(On Diff #387194)

Why does this have to be ptr<ptr>? Isn't one level of indirection enough? (Sorry about the ignoramus question)

flang/test/Fir/types-to-llvm.fir
78 ↗(On Diff #387194)

That is a good question. I don't know the exact reason. I guess it is the following.

  1. Boxes are always references. I think this is modelled by the outer ptr.
  2. The Fortran construct it models is a procedure pointer and this is the inner ptr.

If we consider a function that takes in a procedure pointer as argument, I think in LLVM IR this would require one load to get the value corresponding to the procedure (captured by a procedure pointer) and then an indirect call to call the loaded procedure.

WDYT?

fir.boxproc most likely needs some more work. I don't think it has been used, so it's more of a placeholder.

It is ultimately intended for creating thunks at runtime to implement function pointers. In Fortran, we can have "normal" function pointers and function pointers that must adjust to the calling context as the callee requires access to the host activation on the stack. The boxproc is an abstraction that lets one bind the function pointer and the pointer to the host's data.

I suspect that the intent was something like ptr<struct<ptr<func>, ptr<host-data>>>.

The codegen to build the thunk using the LLVM trampoline intrinsics (https://llvm.org/docs/LangRef.html#trampoline-intrinsics) should be completed here.

The boxproc type and the related operations are not ready. Notify failures for these.

kiranchandramohan retitled this revision from [Flang] Add the typeconversion to llvm for the FIR boxproc type to [Flang] Notify conversion failure for Proc ops, types.Nov 16 2021, 12:56 PM
kiranchandramohan edited the summary of this revision. (Show Details)
This revision is now accepted and ready to land.Nov 16 2021, 1:02 PM
flang/test/Fir/convert-to-llvm-invalid.fir
82

The test is failing here.

I think it is not possible to test unboxproc and boxprochost because they need a value of tupe fir.boxproc. Since the fir.boxproc type is not convertible it is not possible to provide such a value to unboxproc or boxprochost.

Also it seems the conversion is bailing out at the first error, so it is not possible to check multiple errors.

Since the boxproc​ type has no conversion, it is not possible to test unboxproc​
and boxproc_host​ ops. Remove tests for these and add a comment.

flang/test/Fir/types-to-llvm.fir
78 ↗(On Diff #387194)

@rovka After further investigation and discussions we decided to notify failures for the boxproc type and the proc based ops. Is the patch OK now?

rovka accepted this revision.Nov 18 2021, 2:21 AM

Yes, LGTM, thanks!