This is an archive of the discontinued LLVM Phabricator instance.

[flang][hlfir] lower hlfir.shape_of
ClosedPublic

Authored by tblah on Mar 24 2023, 10:44 AM.

Details

Summary

If possible the shape is gotten from the definition of the hlfir.expr
argument. Otherwise one is synthesized from the extent information in
the hlfir::ExprType.

The simple cases should already have been resolved during lowering. This
is mostly intended for cases where shape information is added in between
lowering and the end of bufferization (for example transformational
intrinsics).

Depends on: D146832

Diff Detail

Event Timeline

tblah created this revision.Mar 24 2023, 10:44 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptMar 24 2023, 10:44 AM
tblah requested review of this revision.Mar 24 2023, 10:44 AM
jeanPerier added inline comments.
flang/lib/Optimizer/HLFIR/Transforms/BufferizeHLFIR.cpp
179

I think you can get away with a much simpler approach that will cover all cases: the ShapeOfOp operand was translated to an hlfir::Entity that is a variable: you can "simply" call genShape on it (it knows of to retrieve the fir.shape from variables, or to emit fir.box_dim as needed):

hlfir::Entity bufferizedExpr{getBufferizedExprStorage(adaptor.getExpr())};
assert(bufferizedExpr.isVariable() && "array hlfir.expr are bufferized in memory");
mlir::Value shape = hlfir::genShape(loc, builder, bufferizedExpr);
rewriter.replaceOp(shapeOf, shape);
return mlir::success();
tblah updated this revision to Diff 513202.Apr 13 2023, 5:56 AM
tblah marked an inline comment as done.

Updating to use the simpler implementation suggested by Jean.

tblah added inline comments.Apr 13 2023, 5:58 AM
flang/lib/Optimizer/HLFIR/Transforms/BufferizeHLFIR.cpp
179

Thanks for this, that's a much more elegant solution.

jeanPerier accepted this revision.Apr 14 2023, 1:43 AM

Looks great, thanks. Beware that there is also some patch application issue though.

flang/lib/Optimizer/HLFIR/Transforms/BufferizeHLFIR.cpp
196

Did you hit the TODO, or is this here to be safe?

I am not expecting that bufferizedExpr.isVariable() should ever return false here (shape_of must be used on arrays, arrays must be placed in memory by this pass, genShape must succeed for variables), but I am ok with having a TODO to be safe for now.

This revision is now accepted and ready to land.Apr 14 2023, 1:43 AM
tblah marked an inline comment as done.Apr 14 2023, 3:34 AM
tblah added inline comments.
flang/lib/Optimizer/HLFIR/Transforms/BufferizeHLFIR.cpp
196

No I haven't hit this TODO in practice. It is just there to be safe. I'll change it to return mlir::failure

tblah edited the summary of this revision. (Show Details)Apr 14 2023, 4:18 AM
tblah updated this revision to Diff 513540.Apr 14 2023, 4:27 AM
tblah marked an inline comment as done.

Change from using a TODO to mlir::emitError to make it clearer that this
error condition is not known to occur in real code - it is just there for
safety.

This revision was landed with ongoing or failed builds.Apr 17 2023, 6:28 AM
This revision was automatically updated to reflect the committed changes.