This is an archive of the discontinued LLVM Phabricator instance.

[flang][hlfir] allow assoicate where the expr is also used by shape_of
ClosedPublic

Authored by tblah on Jul 5 2023, 9:28 AM.

Details

Summary

This fixes the majority of cases where we hit the "hlfir.associate of
hlfir.expr with more than one use" TODO. In particular, this allows cam4
to be built.

hlfir.shape_of is just a way to delay reading shape information until
after intrinsics have been lowered to FIR runtime calls. It gets the
shape information from reading existing SSA values (e.g. fetching the
shape used when hlfir.declare'ing the variable). It does not actually
read from the bufferized value itself. Therefore hlfir.shape_of doesn't
affect decisions about when to deallocate the buffer.

Diff Detail

Event Timeline

tblah created this revision.Jul 5 2023, 9:28 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptJul 5 2023, 9:28 AM
tblah requested review of this revision.Jul 5 2023, 9:28 AM

Thank you for the change, Tom!

I ended up with alike change when implementing not yet implemented: inquire type parameters of hlfir.expr. Basically, I am adding new get_length use of hlfir.expr, and this triggers the more than one use TODO. At the same time, I have some concerns about this approach. I believe hlfir.shape_of (as well as the new get_length operation) can end up reading the bufferized box, which might be incorrect after the clean-up. I wonder if we need to check for the dominance here, e.g. that the use is safe only if it dominates the end_associate (which would take the clean-up responsibility).

tblah updated this revision to Diff 537418.Jul 5 2023, 10:25 AM
  • Add test
  • Check that the hlfir.shape_of operation dominates the hlfir.end_associate operation
tblah added a comment.Jul 5 2023, 10:29 AM

Thank you for the change, Tom!

I ended up with alike change when implementing not yet implemented: inquire type parameters of hlfir.expr. Basically, I am adding new get_length use of hlfir.expr, and this triggers the more than one use TODO. At the same time, I have some concerns about this approach. I believe hlfir.shape_of (as well as the new get_length operation) can end up reading the bufferized box, which might be incorrect after the clean-up. I wonder if we need to check for the dominance here, e.g. that the use is safe only if it dominates the end_associate (which would take the clean-up responsibility).

Thanks. I have added a simple dominance check. I haven't found any code which need multi-block dominance analysis so I left this as a TODO.

vzakhari added inline comments.Jul 5 2023, 10:41 AM
flang/lib/Optimizer/HLFIR/Transforms/BufferizeHLFIR.cpp
358

Thanks for the update!

I think we should not return true here and at line 341, because we have not processed all the uses yet. A continue should do.

Thanks, apart from Slava's comment about the true -> continue, looks great to me.

tblah updated this revision to Diff 537644.Jul 6 2023, 2:55 AM

Fix control flow, make comments a bit clearer

tblah added inline comments.Jul 6 2023, 2:57 AM
flang/lib/Optimizer/HLFIR/Transforms/BufferizeHLFIR.cpp
358

Good spot! I clearly wasn't doing my best thinking yesterday

vzakhari accepted this revision.Jul 6 2023, 8:18 AM
This revision is now accepted and ready to land.Jul 6 2023, 8:18 AM