[all-commits] [llvm/llvm-project] c5904f: [LV] Fix crash when computing max VF too early

[Cullen Rhodes via All-commits]

  Branch: refs/heads/release/12.x
  Home:   https://github.com/llvm/llvm-project
  Commit: c5904f5c9d32e563e2898e1242d5818e488fe2ee
      https://github.com/llvm/llvm-project/commit/c5904f5c9d32e563e2898e1242d5818e488fe2ee
  Author: Cullen Rhodes <cullen.rhodes at arm.com>
  Date:   2021-02-03 (Wed, 03 Feb 2021)

  Changed paths:
    M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
    A llvm/test/Transforms/LoopVectorize/Hexagon/maximum-vf-crash.ll

  Log Message:
  -----------
  [LV] Fix crash when computing max VF too early

D90687 introduced a crash:

  llvm::LoopVectorizationCostModel::computeMaxVF(llvm::ElementCount, unsigned int):
    Assertion `WideningDecisions.empty() && Uniforms.empty() && Scalars.empty() &&
    "No decisions should have been taken at this point"' failed.

when compiling the following C code:

  typedef struct {
  char a;
  } b;

  b *c;
  int d, e;

  int f() {
    int g = 0;
    for (; d; d++) {
      e = 0;
      for (; e < c[d].a; e++)
        g++;
    }
    return g;
  }

with:

  clang -Os -target hexagon -mhvx -fvectorize -mv67 testcase.c -S -o -

This occurred since prior to D90687 computeFeasibleMaxVF would only be
called in computeMaxVF when a scalar epilogue was allowed, but now it's
always called. This causes the assert above since computeFeasibleMaxVF
collects all viable VFs larger than the default MaxVF, and for each VF
calculates the register usage which results in analysis being done the
assert above guards against. This can occur in computeFeasibleMaxVF if
TTI.shouldMaximizeVectorBandwidth and this target hook is implemented in
the hexagon backend to always return true.

Reported by @iajbar.

Reviewed By: fhahn

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

(cherry picked from commit 8cda227432f1c9ceb63b88802ed8136da97274f1)