[PATCH] D63686: [LFTR] Fix post-inc pointer IV with truncated exit count (PR41998)

Philip Reames via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 1 09:51:21 PDT 2019


reames added a comment.

In D63686#1563512 <https://reviews.llvm.org/D63686#1563512>, @nikic wrote:

> In D63686#1563412 <https://reviews.llvm.org/D63686#1563412>, @nikic wrote:
>
> > Ideally we would not use post-inc form in the middle end and let LSR move to post-inc if profitable. Apart from the issues we're seeing here, this post-inc form is also non-canonical -- clearly `(a + C1) == C2` should canonically be `a == C2-C1`, but we have hacks in InstCombine to preserve this for multi-use cases. There is some relevant discussion on D58633 <https://reviews.llvm.org/D58633> and in particular some samples where using pre-inc form currently causes regressions. The first step would probably be to figure out what is going on there.
>
>
> After looking into this a bit, I think that the problems of D58633 <https://reviews.llvm.org/D58633> do not apply here. The issue there is that InstCombine can fold instructions inside loops that LSR does not understand because it requires loop simplify form. This doesn't apply here because indvars also works on loop simplify form. Given that, I think it should be fine to use pre-inc form in LFTR (possibly post-inc only if it's already used) and let LSR pick up the post-inc transform.


I think we're on the same page here.  Any chance you're motivated to actually do this?  I'd be happy to review.  :)


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63686/new/

https://reviews.llvm.org/D63686





More information about the llvm-commits mailing list