llvm dev - Jan 2022 - Trip count re-computation during Epilog vectorization

Hi,

We are caching TripCount of a loop in
"EpilogueLoopVectorizationInfo.TripCount"  during first pass ( Main
Loop)
vectorization.
I see we use the cached value at
"emitMinimumVectorEpilogueIterCountCheck"
during the second pass( Epilog Vector loop).

--Snip--
BasicBlock *
EpilogueVectorizerEpilogueLoop::emitMinimumVectorEpilogueIterCountCheck(
    Loop *L, BasicBlock *Bypass, BasicBlock *Insert) {

  assert(EPI.TripCount &&
         "Expected trip count to have been safed in the first pass.");
  assert(
      (!isa<Instruction>(EPI.TripCount) ||
       DT->dominates(cast<Instruction>(EPI.TripCount)->getParent(),
Insert)) &&
      "saved trip count does not dominate insertion point.");
  Value *TC = EPI.TripCount;
 --Snip--

Can  that be used in other places also in second pass?   (*TripCount
EPI.TripCount*).  In the trunk I see we are recomputing again via
getOrCreateTripCount(L)  during the second pass (Epilog vector loop)
is it guaranteed that trip count will always dominate the epilog vector
loop  and scalar loop ?

regards,
Venkat.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20220126/352b649e/attachment.html>

Hi,
> Can  that be used in other places also in second pass?   (TripCount
EPI.TripCount).
Perhaps it could, but I'm not sure why we'd do that? EPI is only
available
to the interfaces specifically extended for epilogue vectorization, and
overwriting TripCount from EPI seems awkward, especially because
`getOrCreateTripCount` takes a loop as input.
> is it guaranteed that trip count will always dominate the epilog vector
loop  and scalar loop ?
The `getOrCreateTripCount` for the original loop is currently first called
when generating the first set of tripcount checks in a basic block that
dominates the main vector, epilogue vector and the scalar loops. This
diagram might help:
https://llvm.org/docs/Vectorizers.html#epilogue-vectorization

BTW, the community is migrating away from the dev-mailing list in favour of
Discourse. Please post future questions to
https://llvm.discourse.group/c/ir-optimizations.

Bardia Mahjour
Compiler Optimizations
IBM Toronto Software Lab




From:	"Venkataramanan Kumar" <venkataramanan.kumar.llvm at
gmail.com>
To:	"llvm-dev" <llvm-dev at lists.llvm.org>, "Florian
Hahn"
            <florian_hahn at apple.com>, "Bardia Mahjour"
            <bmahjour at ca.ibm.com>
Date:	2022/01/26 08:20 AM
Subject:	[EXTERNAL] Trip count re-computation during Epilog
            vectorization



Hi,  We are caching TripCount of a loop in
"EpilogueLoopVectorizationInfo.TripCount"  during first pass ( Main
Loop)
vectorization.  I see we use the cached value at
"emitMinimumVectorEpilogueIterCountCheck" during the
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

Hi,

We are caching TripCount of a loop in
"EpilogueLoopVectorizationInfo.TripCount"  during first pass ( Main
Loop)
vectorization.
I see we use the cached value at
"emitMinimumVectorEpilogueIterCountCheck"
during the second pass( Epilog Vector loop).

--Snip--
BasicBlock *
EpilogueVectorizerEpilogueLoop::emitMinimumVectorEpilogueIterCountCheck(
    Loop *L, BasicBlock *Bypass, BasicBlock *Insert) {

  assert(EPI.TripCount &&
         "Expected trip count to have been safed in the first pass.");
  assert(
      (!isa<Instruction>(EPI.TripCount) ||
       DT->dominates(cast<Instruction>(EPI.TripCount)->getParent(),
Insert)) &&
      "saved trip count does not dominate insertion point.");
  Value *TC = EPI.TripCount;
 --Snip--

Can  that be used in other places also in second pass?   (TripCount
EPI.TripCount).  In the trunk I see we are recomputing again via
getOrCreateTripCount(L)  during the second pass (Epilog vector loop)
is it guaranteed that trip count will always dominate the epilog vector
loop  and scalar loop ?

regards,
Venkat.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20220126/bbf3bda6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20220126/bbf3bda6/attachment.gif>