Page MenuHomePhabricator

[NaryReassociate] allow candidate to have a different type
ClosedPublic

Authored by jingyue on Dec 17 2015, 11:06 AM.

Details

Summary

If Candiadte may have a different type from GEP, we should bitcast or
pointer cast it to GEP's type so that the later RAUW doesn't complain.

Added a test in nary-gep.ll

Diff Detail

Repository
rL LLVM

Event Timeline

jingyue updated this revision to Diff 43159.Dec 17 2015, 11:06 AM
jingyue retitled this revision from to [NaryReassociate] allow candidate to have a different type.
jingyue updated this object.
jingyue added a reviewer: meheff.
jingyue added a subscriber: llvm-commits.
mcrosier added inline comments.
lib/Transforms/Scalar/NaryReassociate.cpp
432 ↗(On Diff #43159)

This might be a silly question, but am I correct in assuming the IR builder will just return the Candidate if the types already match? Hence, the reason we don't need a check prior to the call to CreateBitOrPointerCast. Of course if we did the check up front we wouldn't need to create the builder... ..and if the common case is that they do match, then we might consider predicating all this logic.

jingyue added inline comments.Dec 18 2015, 1:38 PM
lib/Transforms/Scalar/NaryReassociate.cpp
432 ↗(On Diff #43159)

Right, IRBuilder will just return Candidate if the types already match, so we don't need predicating.

This revision was automatically updated to reflect the committed changes.