[all-commits] [llvm/llvm-project] 1721ff: [GVN] Enable enable-split-backedge-in-load-pre opt...

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1721ff1dfd4592f1a391d9161627e2a68198a44e
      https://github.com/llvm/llvm-project/commit/1721ff1dfd4592f1a391d9161627e2a68198a44e
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2022-05-30 (Mon, 30 May 2022)

  Changed paths:
    M llvm/lib/Transforms/Scalar/GVN.cpp
    M llvm/test/Transforms/GVN/PRE/load-pre-metadata-accsess-group.ll
    M llvm/test/Transforms/GVN/PRE/pre-loop-load-through-select.ll
    M llvm/test/Transforms/GVN/PRE/rle.ll
    M llvm/test/Transforms/GVN/PRE/volatile.ll
    M llvm/test/Transforms/GVN/condprop-memdep-invalidation.ll
    M llvm/test/Transforms/PhaseOrdering/X86/vector-reduction-known-first-value.ll

  Log Message:
  -----------
  [GVN] Enable enable-split-backedge-in-load-pre option by default

This option was added in D89854. It prevents GVN from performing
load PRE in a loop, if doing so would require critical edge
splitting on the backedge. From the review:

> I know that GVN Load PRE negatively impacts peeling,
> loop predication, so the passes expecting that latch has
> a conditional branch.

In the PhaseOrdering test in this patch, splitting the backedge
negatively affects vectorization: After critical edge splitting,
the loop gets rotated, effectively peeling off the first loop
iteration. The effect is that the first element is handled
separately, then the bulk of the elements use a vectorized
reduction (but using unaligned, off-by-one memory accesses) and
then a tail of 15 elements is handled separately again.

It's probably worth noting that the loop load PRE from D99926 is
not affected by this change (as it does not need backedge
splitting). This is about normal load PRE that happens to occur
inside a loop.

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