[all-commits] [llvm/llvm-project] d77a36: [LoopVectorize] Use new getUniqueLatchExitBlock ro...

[David Sherwood via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d77a36e01b8fed496b29c3b2c12526f8dc380766
      https://github.com/llvm/llvm-project/commit/d77a36e01b8fed496b29c3b2c12526f8dc380766
  Author: David Sherwood <david.sherwood at arm.com>
  Date:   2024-11-06 (Wed, 06 Nov 2024)

  Changed paths:
    M llvm/include/llvm/Support/GenericLoopInfo.h
    M llvm/include/llvm/Support/GenericLoopInfoImpl.h
    M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp

  Log Message:
  -----------
  [LoopVectorize] Use new getUniqueLatchExitBlock routine (#108231)

With PR #88385 I am introducing support for vectorising more loops with
early exits that don't require a scalar epilogue. As such, if a loop
doesn't have a unique exit block it will not automatically imply we
require a scalar epilogue. Also, in all places in the code today where
we use the variable LoopExitBlock we actually mean the exit block from
the latch. Therefore, it seemed reasonable to add a new
getUniqueLatchExitBlock that allows the caller to determine the exit
block taken from the latch and use this instead of getUniqueExitBlock. I
also renamed LoopExitBlock to be LatchExitBlock. I feel this not only
better reflects how the variable is used today, but also prepares the
code for PR #88385.

While doing this I also noticed that one of the comments in
requiresScalarEpilogue is wrong when we require a scalar epilogue, i.e.
when we're not exiting from the latch block. This doesn't always imply
we have multiple exits, e.g. see the test in

Transforms/LoopVectorize/unroll_nonlatch.ll

where the latch unconditionally branches back to the only exiting block.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications