This effectively reverts D154715.
The issue appears as the dialect conversion error because we try to
erase an op that has already been erased. See the added LIT test case
with HLFIR that may appear as a result of CSE.
The adaptor.getSource() is an operation producing a tuple,
which does not have users, so allOtherUsesAreSafeForAssociate
just looks at the empty list of users. So we get completely wrong
answers from it. This causes problems with the following
eraseAllUsesInDestroys that tries to remove the DestroyOp twice
during both hflir.associate processing.
But we also cannot use associate.getSource() *efficiently*, because
the original users may still hang around: one example is the original body
of hlfir.elemental (see D154715), another example is other already converted
AssociateOp's that are pending removal in the rewriter
(that is why we have a temporary created for each hlfir.associate
in the newly added LIT case).
This patch just fixes the correctness issue. I think we have to separate
the buffer reuse analysis from the conversion itself.
I also tried to address the issues with the cloned bodies of hlfir.elemental,
but this should not matter since D155778: if hlfir.associate is inside
hlfir.elemental, it will end up inside a do-loop body region, so the early
exit added in D155778 will prevent the buffer reuse.
I wonder if using the conversion pattern rewriter driver is creating more trouble than it is worth in this patch. Personally, I find these sorts of things makes this pass very difficult to debug.
How would you feel about using the greedy pattern rewriter API instead? This way updates would be immediately visible.