Useful metadata like llvm.loop can be lost when the new branch instruction is created. Grab that metadata from the old branch.
Add a correct LIT test to check
Details
- Reviewers
nikic
Diff Detail
Event Timeline
LGTM, but I do wonder whether we aren't working around a different issue here. JumpThreading generally does not perform threading across loop headers (it's behind a default-disabled option). As far as I understand, the select unfolding is just done to enable future threading. In this case, we unfold the select, but then can't thread it because that would require threading across a header.
We're left with what appear to me an unprofitable transform: We now have two loop latches, which is non-canonical. LoopSimplify will have to convert this back into a single latch.
So my thinking is that we should probably prevent select unfolding from happening here in the first place. I see that tryToUnfoldSelectInCurrBB() already guards against this, but tryToUnfoldSelec() does not.