This NFC splitting is intended to make a later diff easier to follow.
It just tail duplicates cloneIVUser into cloneArithmeticIVUser and
cloneBitwiseIVUser.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
I'm a bit confused by the need/desirability of this change. Isn't it fairly simple to make the special case for widening conditional on the operator type within a single function? Or is there something more fundamental I'm missing?
Firstly, the structure of cloneArithmeticIVUser will end up being a little different from cloneBitwiseIVUser; and I think having an "early dispatch" will make it easier to avoid bugs. This is the practical reason why I split the two.
There is a more fundamental difference between the two as well, which I've not drawn attention to here, because it isn't being used -- SCEV is usually to unable to analyze bitwise operations like x & y (unless they're just optimized arithmetic). This means we don't widen uses of IVs like and %iv, 42 (and insert a trunc) even though bitwise operations are (almost by definition) easy to widen (zext (and %iv, 42) == and zext(%iv), zext(42)). -instcombine is usually able to clean these (the trunc s) up, but if we later find interesting cases that -instcombine cannot clean up then we could make cloneBitwiseIVUser smarter, which would further diverge the implementations.