[all-commits] [llvm/llvm-project] 932ae4: [IndVars] Improve handling of multi-exit loops wit...

Max Kazantsev via All-commits all-commits at lists.llvm.org
Mon Jan 23 21:58:51 PST 2023


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 932ae48c273c590449649ed3cc7b752511a85665
      https://github.com/llvm/llvm-project/commit/932ae48c273c590449649ed3cc7b752511a85665
  Author: Max Kazantsev <mkazantsev at azul.com>
  Date:   2023-01-24 (Tue, 24 Jan 2023)

  Changed paths:
    M llvm/lib/Transforms/Scalar/IndVarSimplify.cpp
    M llvm/test/Transforms/IndVarSimplify/turn-to-invariant.ll

  Log Message:
  -----------
  [IndVars] Improve handling of multi-exit loops with known symbolic counts

This patch does two things, both related to support of multi-exit loops with
many exits that have known symbolic max exit count. They can theoretically
go independently, but I don't know how to write a test showing separate
impact.

Part 1: `SkipLastIter` can be set to `true` not when a particular exit has exit
count same as the whole loop (and therefore it must exit on the last iteration),
but when the aggregate of first few exits has umin same as whole loop exit count.
It means that it's not known which of them will exit exactly, but one of them will.

Part 2: when `SkipLastIter` is set, and exit count is `umin(a, b, c)`, instead of
`umin(a, b, c) - 1` use `umin(a - 1, b - 1, c - 1)`. We don't care about overflows
here, but the further logic knows how to deal with umin by element, but the
`SCEVAddExpr` node will confuse it.

Differential Revision: https://reviews.llvm.org/D141361
Reviewed By: nikic




More information about the All-commits mailing list