[all-commits] [llvm/llvm-project] 156f10: [IR] `SCEVExpander::generateOverflowCheck()`: shor...

[Roman Lebedev via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 156f10c840a07034a6bd638b5912054100365741
      https://github.com/llvm/llvm-project/commit/156f10c840a07034a6bd638b5912054100365741
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2021-10-27 (Wed, 27 Oct 2021)

  Changed paths:
    M llvm/lib/Transforms/Utils/ScalarEvolutionExpander.cpp
    M llvm/test/Transforms/LoopVectorize/X86/illegal-parallel-loop-uniform-write.ll
    M llvm/test/Transforms/LoopVectorize/first-order-recurrence-complex.ll
    M llvm/test/Transforms/LoopVectorize/pr45259.ll
    M llvm/test/Transforms/LoopVectorize/runtime-check-needed-but-empty.ll
    M llvm/test/Transforms/LoopVectorize/runtime-check-small-clamped-bounds.ll

  Log Message:
  -----------
  [IR] `SCEVExpander::generateOverflowCheck()`: short-circuit `umul_with_overflow`-by-one

It's a no-op, no overflow happens ever: https://alive2.llvm.org/ce/z/Zw89rZ

While generally i don't like such hacks,
we have a very good reason to do this: here we are expanding
a run-time correctness check for the vectorization,
and said `umul_with_overflow` will not be optimized out
before we query the cost of the checks we've generated.

Which means, the cost of run-time checks would be artificially inflated,
and after https://reviews.llvm.org/D109368 that will affect
the minimal trip count for which these checks are even evaluated.
And if they aren't even evaluated, then the vectorized code
certainly won't be run.

We could consider doing this in IRBuilder,  but then we'd need to
also teach `CreateExtractValue()` to look into chain of `insertvalue`'s,
and i'm not sure there's precedent for that.

Refs. https://reviews.llvm.org/D109368#3089809