This patch allows sinking an instruction which can have multiple uses in a
single user. We were previously over-restrictive by looking for exactly one use,
rather than one user.
Also added an API for retrieving a unique undroppable user.
Differential D109700
[InstCombine] Improve TryToSinkInstruction with multiple uses anna on Sep 13 2021, 9:03 AM. Authored by
Details This patch allows sinking an instruction which can have multiple uses in a Also added an API for retrieving a unique undroppable user.
Diff Detail
Event Timeline
Comment Actions I don't follow. This is not a rename. It is an API change where we return a unique *User* instead of a use.
Comment Actions The change looks reasonable to me.
Comment Actions addressed review comments.
Comment Actions Please disregard. My actual question was intended to be more along the lines of: Comment Actions LGTM
Comment Actions Ah. Yes, I went through the same process when deciding to replace the original API :)
Comment Actions Early warning signs, looks like it broke the sanitizer fast bot: https://lab.llvm.org/buildbot/#/builders/5/builds/11759 Unclear whether this patch is fully responsible, or the bot's ccache is messed up. Comment Actions Breakage on regular fastbot was probably occluded as the bot was already red, but it's broken there too: https://lab.llvm.org/buildbot/#/builders/109/builds/22459 Comment Actions Thank you for the failure notifications. I have landed the fixes in tree: If it still fails, I will revert the change and investigate tomorrow. So, getSingleUndroppableUser is needed for AssumeBundleBuilder. Added the API back and also continued using it in AssumeBundleBuilder (the second commit above). Sorry for the noise here. EoD is never a good time to land. Should have waited till ninja check passed. Comment Actions So i guess my question was correct then :/ Comment Actions Narrower change compared to previous one: getUniqueUndroppableUser API introduced is only used within InstCombine. Comment Actions The change is narrower now and updated test cases in SLPVectorizer (no surprises in the updates). Comment Actions Still LGTM, though I'd be interested in knowing what was wrong with the AssumeBundleBuilder case. It's not entirely obvious to me why the switch to getUniqueUndroppableUser() caused issues there. Comment Actions I will check that separately and address. The lit testcase may just require an update. However, the unit-test which fails building (because of absence of the use API: getSingleUndroppableUse) |
This comment wasn't true even before the patch. We are traversing the entire use list here to find the "non-droppable use". I can land this separately.