[all-commits] [llvm/llvm-project] 53dacb: [LV] Generate RT checks up-front and remove them i...

[Florian Hahn via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 53dacb7b67758f0c5ea2fe6a3c2030d070017b42
      https://github.com/llvm/llvm-project/commit/53dacb7b67758f0c5ea2fe6a3c2030d070017b42
  Author: Florian Hahn <flo at fhahn.com>
  Date:   2021-03-01 (Mon, 01 Mar 2021)

  Changed paths:
    M llvm/include/llvm/Transforms/Utils/ScalarEvolutionExpander.h
    M llvm/lib/Transforms/Utils/ScalarEvolutionExpander.cpp
    M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
    M llvm/test/Transforms/LoopVectorize/X86/illegal-parallel-loop-uniform-write.ll
    M llvm/test/Transforms/LoopVectorize/pr47343-expander-lcssa-after-cfg-update.ll
    A llvm/test/Transforms/LoopVectorize/runtime-drop-crash.ll
    M llvm/test/Transforms/LoopVectorize/skeleton-lcssa-crash.ll

  Log Message:
  -----------
  [LV] Generate RT checks up-front and remove them if required.

This patch updates LV to generate the runtime checks just after cost
modeling, to allow a more precise estimate of the actual cost of the
checks. This information will be used in future patches to generate
larger runtime checks in cases where the checks only make up a small
fraction of the expected scalar loop execution time.

The runtime checks are created up-front in a temporary block to allow better
estimating the cost and un-linked from the existing IR. After deciding to
vectorize, the checks are moved backed. If deciding not to vectorize, the
temporary block is completely removed.

This patch is similar in spirit to D71053, but explores a different
direction: instead of delaying the decision on whether to vectorize in
the presence of runtime checks it instead optimistically creates the
runtime checks early and discards them later if decided to not
vectorize. This has the advantage that the cost-modeling decisions
can be kept together and can be done up-front and thus preserving the
general code structure. I think delaying (part) of the decision to
vectorize would also make the VPlan migration a bit harder.

One potential drawback of this patch is that we speculatively
generate IR which we might have to clean up later. However it seems like
the code required to do so is quite manageable.

Reviewed By: lebedev.ri, ebrevnov

Differential Revision: https://reviews.llvm.org/D75980