This is an archive of the discontinued LLVM Phabricator instance.

[flang] hlfir.associate and hlfir.end_associate codegen
ClosedPublic

Authored by jeanPerier on Nov 30 2022, 8:24 AM.

Details

Summary

Add hlfir.associate and hlfir.end_associate codegen.
To properly allow reusing the bufferized expression storage for the
newly created variable, bufferization of hlfir.expr has to be updated
so that hlfir.expr are translated to a variable and a boolean to
indicate if the variable storage needs to be freed after the expression
was used. That way the responsibility to free the bufferized expression
can be passed to the variable user, and applied in the
hlfir.end_associate.

Right now, not of the bufferized expression are heap allocated, so
generating the conditional freemem in hlfir.end_associate is left as
a TODO for when it can be tested.

Diff Detail

Event Timeline

jeanPerier created this revision.Nov 30 2022, 8:24 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 30 2022, 8:24 AM
jeanPerier requested review of this revision.Nov 30 2022, 8:24 AM

All builds and tests correctly and looks good. But I don't understand this code very well so it would be good to get an approval from @clementval or @vzakhari.

vzakhari added inline comments.Nov 30 2022, 11:28 AM
flang/lib/Optimizer/HLFIR/Transforms/BufferizeHLFIR.cpp
65

It looks like there is an implicit assumption that there are no mlir::TupleType operands in the operations that are transformed by this pass before this pass launches OR if such operands are present and they match the tuple<variable address, cleanupFlag> pattern, then they indeed represent the bufferization package. Am I reading it right? It seems somewhat subtle to me, and I would rather use a distinct FIR type to represent the package so that values of this type have a well-defined meaning. I guess it should be okay as-is if we do not expect mlir::TupleType operands ever appear elsewhere.

134

nit: unnecessary doxygen-style comment '///'.

jeanPerier updated this revision to Diff 479217.Dec 1 2022, 2:46 AM

Add descriptions around the helper to create tuples for bufferized
expressions and extract the storage/cleanup flag from these tuples.

jeanPerier marked an inline comment as done.EditedDec 1 2022, 2:48 AM

Thanks for the review Slava and Pete

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

There are no tuple operands before this pass. The operands of HLFIR ops have toe be hlfir.expr or HLFIR variable types, and tuple are not accepted by the verifiers. This full translation pass is translating hlfir.expr<T> types to tuple<fir.ref/box<T>, i1>. This helper is indeed relying on the fact that there are not other usage of tuple types.

I agree that introducing a new type would be nicer. But it would require adding ops to create/read them, and a pass to get rid of the type because convert-hlfir-to-fir cannot convert types (it is not a full rewrite pass to keep it simpler). So given the tuple creations and usages are internal to this file, I think it is OK to rely on the fact that other tuples cannot make it in this helpers.
If it turns out we need something more solid because there is another use case for tuples as HLFIR operation operands, it will be OK to pay the price of adding a new type then.

I added a comment to make the assumption clear.

vzakhari accepted this revision.Dec 1 2022, 8:48 AM
vzakhari added inline comments.
flang/lib/Optimizer/HLFIR/Transforms/BufferizeHLFIR.cpp
65

Thank you for the explanation and the comments! It looks good to me.

Going forward, I think, we can try to keep using fir.undefined and fir.insert_value operations with the new type by extending AnyCompositeLike constraint.

This revision is now accepted and ready to land.Dec 1 2022, 8:48 AM
This revision was automatically updated to reflect the committed changes.