This is an archive of the discontinued LLVM Phabricator instance.

[flang] Fix lowering of optional char proc args
ClosedPublic

Authored by luporl on Feb 24 2023, 9:08 AM.

Details

Summary

Optional character function arguments were not being lowered
properly. As they are passed as a tuple, containing the (boxed)
function address and the character length, it is not possible for
fir.absent to handle it directly. Instead, a tuple needs to be
created and filled with an absent function address and a dummy
character length.

Fixes #60225

Diff Detail

Event Timeline

luporl created this revision.Feb 24 2023, 9:08 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
luporl requested review of this revision.Feb 24 2023, 9:08 AM

Thanks a lot for the fix!

flang/lib/Lower/ConvertExpr.cpp
2463–2474

Can I ask you to move this code into a new FirOpBuilder helper builder.genAbsentOp(loc, argTy) that would detect that the argTy is a tuple via fir::isCharacterProcedureTuple(argTy), and use fir::factory::createCharacterProcedureTuple instead of createBoxProcCharTuple to create the tuple?

That way, it can be reused in other places that also suffer from this bug, like the equivalent HLFIR code pieces here:

2470

I would use fir.undefined or zero rather than 1 for the length of an absent character procedure.

Thanks for the review!

flang/lib/Lower/ConvertExpr.cpp
2463–2474

Right, I'll make this change and fix these HLFIR code pieces.

luporl updated this revision to Diff 501184.Feb 28 2023, 9:36 AM
  • Use fir.undefined as character length
  • Move lowering fix to builder.genAbsentOp
  • Fix HLFIR and test it
luporl marked 2 inline comments as done.Feb 28 2023, 9:37 AM

Thanks a lot, I think the IR can be slightly further simplify by merging the fir.absent and fir.emboxproc into a single fir.absent. Looks great otherwise.

flang/lib/Optimizer/Builder/FIRBuilder.cpp
619

Nit: single line if/for... should not have braces in LLVM/MLIR coding style (it's a bit of brain gymnastic...)

https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements

623–627

Thinking this through a bit more, doesn't auto boxProc = create<fir::AbsentOp>(loc, argTy.cast<mlir::TupleType>().getType(0)); works an save the EmboxProc at that level?
I think AbsentOp should work properly on BoxProcType (otherwise, there would also be a bug for optional non character dummy procedures).

It will probably also make the extension of this code to optional character pointer procedure easier when they arrive (nothing to do other than updating the isCharacterProcedureTuple to detect them).

luporl added inline comments.Mar 1 2023, 2:02 PM
flang/lib/Optimizer/Builder/FIRBuilder.cpp
623–627

I've tried this and it works (assembly seems correct and test program runs without errors).

I'm just a bit worried about the generated FIR, that has an unconditional fir.box_addr on the absent BoxProc, in the if (present(arg)) part. Is fir.box_addr guaranteed to work with fir.absent BoxProcs?

jeanPerier added inline comments.Mar 2 2023, 7:53 AM
flang/lib/Optimizer/Builder/FIRBuilder.cpp
623–627

Is fir.box_addr guaranteed to work with fir.absent BoxProcs?

Yes, it's fine. I agree it is not supper nice to do this box_addr + embox_proc. It is a bit useless an noisy, but is not related to your patch.

The box_addr is probably generated here: https://github.com/llvm/llvm-project/blob/cedfd2721e3492e5ab0ea86d24d8027846687c27/flang/lib/Lower/ConvertProcedureDesignator.cpp#L63, but it would need to be tested that the box_addr part can be skipped (that the code in lowering is OK with getting a fir.boxproc), so I would not try to change this in this patch.

luporl added inline comments.Mar 2 2023, 8:28 AM
flang/lib/Optimizer/Builder/FIRBuilder.cpp
623–627

Ok, thanks for the detailed explanation. Then I'll go ahead with this change.

luporl updated this revision to Diff 501888.Mar 2 2023, 9:06 AM
  • Simplify IR
luporl marked 3 inline comments as done.Mar 2 2023, 9:07 AM
jeanPerier accepted this revision.Mar 3 2023, 12:19 AM

Thanks for having dealt with all the comments, LGTM

This revision is now accepted and ready to land.Mar 3 2023, 12:19 AM
This revision was automatically updated to reflect the committed changes.