[PATCH] D109676: [HardwareLoops] put +1 for loop count before zero extension

[ChenZheng via Phabricator via llvm-commits]

shchenz added a comment.

In D109676#3055431 <https://reviews.llvm.org/D109676#3055431>, @reames wrote:

> In D109676#3039130 <https://reviews.llvm.org/D109676#3039130>, @shchenz wrote:
>
>> Hi @reames , do you have further comments for this patch? Thanks.
>
> Sorry, your last response didn't parse for me.  I know the SCEV side of this, but the client pieces are going over my head.
>
> My general suggestion is to rebase over D110587 <https://reviews.llvm.org/D110587> (which I'm about to land), and cleanup any downstream handling of zero trip counts separately.
>
> We've about hit the limit of my ability to provide useful review on this, JFYI.

Hi @reames , seems for this client side, Modified `getTripCountFromExitCount` in D110587 <https://reviews.llvm.org/D110587> can not be used. `getTripCountFromExitCount` always return a wider type(1 bit larger than `ExitCount->type` size). Because of hardware loop counter register length limitation, the `ExitCount->type` must be smaller than loop counter register length(For example on 64-bit PowerPC, loop counter register length is 64-bit).
So without calling the API in D110587 <https://reviews.llvm.org/D110587>, we can use a i64 type ExitCount, if we can prove ExitCount + 1 does not overflow by calling `isLoopEntryGuardedByCond`. But if we call `getTripCountFromExitCount` with parameter `Extend=true`, the i64 exitcount/tripcount will be extended to i65 which is not a right loop counter type, so we can not use this i64 type ExitCount even it will not overflow after +1.

Thoughs? Please take your time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109676