This is an archive of the discontinued LLVM Phabricator instance.

Remove builder that takes SSA value instead of Attribute on ExtractValueOp, InsetValueOp, and InsertOnRangeOp
ClosedPublic

Authored by mehdi_amini on Nov 1 2021, 12:22 PM.

Details

Summary

This builder exposed a somehow "unsafe" API: it pretends we can
construct an InsertOnRangeOp from a range of SSA values, even though
this will crash if these aren't the result of arith.constant since
the operation actually needs attribute values (a build method can't
fail gracefully).
That means that the caller must check for the producer, at which
point they can just assemble the attribute array directly and call
the existing builder.

The existing call-sites were even in a worse state here: they would
actually create a constant operation that wouldn't be used and only
serve to carry the attribute through the builder API.

Diff Detail

Event Timeline

mehdi_amini created this revision.Nov 1 2021, 12:22 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 1 2021, 12:22 PM
mehdi_amini requested review of this revision.Nov 1 2021, 12:22 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 1 2021, 12:22 PM

The pre-merge checks are failing during the build. Looks like there is a use of the builder somewhere.

The pre-merge checks are failing during the build. Looks like there is a use of the builder somewhere.

Indeed it was passing before I removed the declaration, which I think shows that this is dead code, but transitively speaking!

The pre-merge checks are failing during the build. Looks like there is a use of the builder somewhere.

Indeed it was passing before I removed the declaration, which I think shows that this is dead code, but transitively speaking!

This is probably left over from the version of the op that had values instead of attributes.

Fix patch: I had removed the declaration on the wrong op!

Turns out I had removed the declaration on InsertValueOp instead of InsertValueOp (/facepalm...)

(that said it showed me some issued with this API on InsertValueOp, I'll follow up.

(that said it showed me some issued with this API on InsertValueOp, I'll follow up.

I guess they have not been cleaned after moving to attribute as well.

mehdi_amini retitled this revision from Remove unused builder from InsertOnRangeOp (NFC) to Remove builder that takes SSA value instead of Attribute on ExtractValueOp, InsetValueOp, and InsertOnRangeOp.
mehdi_amini edited the summary of this revision. (Show Details)

Update to handle ExtractValueOp, InsetValueOp, and InsertOnRangeOp

mehdi_amini added inline comments.
flang/lib/Optimizer/Builder/Character.cpp
697

All these users were emitting spurious operations here!

This looks ok to me. This will need some work downstream since the old build functions is used in couple of places with fir::FieldIndexOp and it is handy to extract the two coordinates attributes from the op and append them as attribute. But I guess we can refactor that.

The pre-merge checks are failing during the build. Looks like there is a use of the builder somewhere.

Indeed it was passing before I removed the declaration, which I think shows that this is dead code, but transitively speaking!

This is probably left over from the version of the op that had values instead of attributes.

The code in the lowering directories is very out of date.

This looks ok to me.

Great, I assume I can land this then!

This revision was not accepted when it landed; it landed in state Needs Review.Nov 2 2021, 3:58 PM
This revision was automatically updated to reflect the committed changes.

This looks ok to me.

Great, I assume I can land this then!

I was still checking the repercussion of this on the code that still need to be upstreamed. Next time please wait for the formal approval.

This looks ok to me.

Great, I assume I can land this then!

I was still checking the repercussion of this on the code that still need to be upstreamed. Next time please wait for the formal approval.

Ah sorry about that! Feel free to revert if there are deeper issues with the direction.

In general I was expecting you to keep this kind of code in your fork as needed to ease the update.