[PATCH] D71563: [SCEV] Recognise the hardwareloop "loop.decrement.reg" intrinsic

[Sanjoy Das (Work Account) via Phabricator via llvm-commits]

sanjoy.google added a comment.

In D71563#1786529 <https://reviews.llvm.org/D71563#1786529>, @SjoerdMeijer wrote:

> Thanks for taking a look!
>
> > `llvm.loop.decrement.reg` is not documented in the langref. Is this a target specific thing?
>
> No, it's a target independent thing, and is generated by the generic Hardwareloop pass. It is defined here:
>
> https://github.com/llvm/llvm-project/blob/ff07fc66d9eef577f3b44716f72e581a18cd9ac9/llvm/include/llvm/IR/Intrinsics.td#L1304
>
> > Also, is the entire gamut of optimizations this enables OK? For instance, would it be okay to LFTR replace the trip count of the loop such that it doesn't use the loop_decrement_reg intrinsic anymore?
>
> Hmmm, I don't have a good answer for that yet. First, just to be clear, the `llvm.loop.decrement.reg` intrinsic is exactly the same as a sub expression, so I think SCEV analysis functions should be okay. But yes, I think I can imagine that SCEV transformations that modify the loop update expression could potentially be problematic. But this is a bit of unexplored territory for me, so first I need to look into what LFTR exactly does. So, I will need to so some homework first, but if we assume for a moment that there will be problematic cases with SCEV transformation modifying the loop update expression (if they would ignore the loop.decremenent intrinsic if there is one present), does that make this approach completely unfeasible, or would you still see possibilities to use the SCEV analysis functions?


I think the right mental model is that SCEV's users can rewrite the loop exit condition in arbitrary ways once SCEV can "understand" it.  It may not be so bad in practice, but this is how I think about it.


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

https://reviews.llvm.org/D71563