Page MenuHomePhabricator

[NaryReassociate] allow candidate to have a different type

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



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


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.
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
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.