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
Paths
| Differential D15618
[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 Added a test in nary-gep.ll
Diff Detail Event Timelinejingyue updated this object. mcrosier added inline comments.
Closed by commit rL256035: [NaryReassociate] allow candidate to have a different type (authored by jingyue). · Explain WhyDec 18 2015, 1:39 PM This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 43159 lib/Transforms/Scalar/NaryReassociate.cpp
test/Transforms/NaryReassociate/NVPTX/nary-gep.ll
|
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.