This is an archive of the discontinued LLVM Phabricator instance.

[flang][hlfir] move intrinsic lowering out of BufferizeHLFIR
ClosedPublic

Authored by tblah on Mar 7 2023, 7:05 AM.

Details

Summary

This move is useful for a few reasons:

  • It is easier to see what the intrinsic lowering is doing when the operations it creates are not immediately lowered
  • When lowering a HLFIR intrinsic generates an operation which needs to be lowered by another pattern matcher in the same pass, MLIR will run that other substitution before validating and finalizing the original changes. This means that the erasure of operations is not yet visible to subsequent matchers, which hugely complicates transformations (in this case, hlfir.exprs cannot be rewritten because they are still used by the now-erased HLFIR intrinsic op.

Diff Detail

Event Timeline

tblah created this revision.Mar 7 2023, 7:05 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
tblah requested review of this revision.Mar 7 2023, 7:05 AM
tblah updated this revision to Diff 504066.Mar 10 2023, 2:19 AM

Update with rebase on upstream (a header moved)

I think the cause of the issue mentioned in the second bullet point is that the patterns were actually not using the OpAdaptor adaptor to get the operands as they should have in a full translation pass (sorry for not catching that, I always miss this....). E.g: sum.getArray() sould have been getBufferizedExprStorage(adaptor.getArray()). And the hlfir::AsExprOp in processReturnValue could have been repaced by packageBufferizedExpr(loc, builder, *resultEntity, mustBeFreed). This would have avoided using/introducing again hlfir.expr in the pass that gets rid of them. This would also address the first point in some way (but I agree the hlfir.expr operands would still also be transformed).

Now, I am not against having this in a separate pass for modularity. The down side is that this has to be a moduleOp pass again because of the runtime calls creation, and these passes cannot be multithreaded, so they are more expensive on multicore machines compiling big Fortran files (where cmake multithreading is not the most useful).

However, if this becomes a separate pass, then it should not be a conversion pass (using the OpConversionPattern): this should use an OpRewritePattern since the operation is rewritten with the a value with the same IR type as the previous operation result (and there is not need for the adaptor in this case).

I do not have a strong take. So I am OK with your patch if you make if an rewrite pass instead of a conversion, and I am also OK with keeping it in the same pass and use the adaptor/remove the created as_expr op.

flang/lib/Optimizer/HLFIR/Transforms/LowerHLFIRIntrinsics.cpp
2

There seems to be a clang-format issue in this file.

tblah updated this revision to Diff 505011.Mar 14 2023, 3:31 AM

Thanks for review, that's very helpful to know.

I will keep it like this because I think it is easier to understand what is
going on when bufferization and intrinsic implementation are separated (in the
future some intrinsic calls might be implemented by local fortran functions like
in the simplify intrinsic pass). Calling the particular runtime methods we
currently use does bufferize expressions now, but that could change in the
future if the non-allocating runtime functions (e.g. MatmulDirect) are used.

Changes:

  • clang-format (sort headers)
  • Switch base class to mlir::OpRewritePattern
tblah marked an inline comment as done.Mar 14 2023, 3:33 AM
tschuett added inline comments.
flang/lib/Optimizer/HLFIR/Transforms/LowerHLFIRIntrinsics.cpp
262

Nit. You claim it to be a ModuleOp pass. Could please spell out the auto.

tblah updated this revision to Diff 505757.Mar 16 2023, 3:33 AM

Changes:

  • Spell out auto
  • Allow unknown operations - this prevents the pass from having to add every MLIR dialect used in Flang (and from breaking when new ones are added).
jeanPerier accepted this revision.Mar 17 2023, 1:12 AM

Thanks, LGTM. Please beware there is a bot failure, but I think it is unrelated to your patch (you could rebase if this was fixed to check that).

This revision is now accepted and ready to land.Mar 17 2023, 1:12 AM
This revision was landed with ongoing or failed builds.Mar 17 2023, 2:31 AM
This revision was automatically updated to reflect the committed changes.
tblah added a comment.Mar 17 2023, 2:32 AM

Thanks, LGTM. Please beware there is a bot failure, but I think it is unrelated to your patch (you could rebase if this was fixed to check that).

Thanks for pointing this out. The failing test was a driver test for RISC-V and it passes on the later patches in this series so I think it is unrelated. I'll revert if there are buildbot failures post commit.