[all-commits] [llvm/llvm-project] 2cb5c6: Scalarizer: limit scalarization for small element ...

[Nicolai Hähnle via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2cb5c6d124d64344fd91eb769438fb81367bb266
      https://github.com/llvm/llvm-project/commit/2cb5c6d124d64344fd91eb769438fb81367bb266
  Author: Nicolai Hähnle <nicolai.haehnle at amd.com>
  Date:   2023-06-13 (Tue, 13 Jun 2023)

  Changed paths:
    M llvm/include/llvm/Transforms/Scalar/Scalarizer.h
    M llvm/lib/Transforms/Scalar/Scalarizer.cpp
    M llvm/test/Transforms/Scalarizer/basic-inseltpoison.ll
    M llvm/test/Transforms/Scalarizer/basic.ll
    M llvm/test/Transforms/Scalarizer/min-bits.ll
    M llvm/test/Transforms/Scalarizer/opaque-ptr-bug.ll
    M llvm/test/Transforms/Scalarizer/vector-gep.ll

  Log Message:
  -----------
  Scalarizer: limit scalarization for small element types

Scalarization can expose optimization opportunities for the individual
elements of a vector, and can therefore be beneficial on targets like
GPUs that tend to operate on scalars anyway.

However, notably with 16-bit operations it is often beneficial to keep
<2 x i16 / half> vectors around since there are packed instructions for
those.

Refactor the code to operate on "fragments" of split vectors. The
fragments are usually scalars, but may themselves be smaller vectors
when the scalarizer-min-bits option is used. If the split is uneven,
the last fragment is a shorter remainder.

This is almost NFC when the new option is unused, but it happens to
clean up some code in the fully scalarized case as well.

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