[PATCH] D85794: [llvm][LV] Replace `unsigned VF` with `ElementCount VF` [NFCI]

[Francesco Petrogalli via Phabricator via llvm-commits]

fpetrogalli created this revision.
Herald added subscribers: llvm-commits, bmahjour, rogfer01, bollu, hiraditya.
Herald added a reviewer: rengolin.
Herald added a project: LLVM.
fpetrogalli requested review of this revision.
Herald added a subscriber: vkmr.

Changes:

- Change `ToVectorTy` to deal directly with `ElementCount` instances.
- `VF == 1` replaced with `VF.isScalar()`.
- `VF > 1` and `VF >=2` replaced with `VF.isVector()`.
- `VF <=1` is replaced with `VF.isZero() || VF.isScalar()`.
- Add `<` operator to `ElementCount` to be able to use

`llvm::SmallSetVector<ElementCount, ...>`.

- Bits and pieces around printing the ElementCount to string streams.
- Added a static method to `ElementCount` to represent a scalar.

To guarantee that this change is a NFC, `VF.Min` and asserts are used
in the following places:

1. When it doesn't make sense to deal with the scalable property, for

example:

  a. When computing unrolling factors.
  b. When shuffle masks are built for fixed width vector types

In this cases, an
assert(!VF.Scalable && "<mgs>") has been added to make sure we don't
enter coepaths that don't make sense for scalable vectors.

2. When there is a conscious decision to use `FixedVectorType`. These

uses of `FixedVectorType` will likely be removed in favour of
`VectorType` once the vectorizer is generic enough to deal with both
fixed vector types and scalable vector types.

3. When dealing with building constants out of the value of VF, for

example when computing the vectorization `step`, or building vectors
of indices. These operation _make sense_ for scalable vectors too,
but changing the code in these places to be generic and make it work
for scalable vectors is to be submitted in a separate patch, as it is
a functional change.

4. When building the potential VFs in VPlan. Making the VPlan generic

enough to handle scalable vectorization factors is a functional change
that needs a separate patch. See for example `void
LoopVectorizationPlanner::buildVPlans(unsigned MinVF, unsigned
MaxVF)`.

5. The class `IntrinsicCostAttribute`: this class still uses `unsigned

VF` as updating the field to use `ElementCount` woudl require changes
that could result in changing the behavior of the compiler. Will be done
in a separate patch.

7. When dealing with user input for forcing the vectorization

factor. In this case, adding support for scalable vectorization is a
functional change that migh require changes at command line.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D85794

Files:
  llvm/include/llvm/Analysis/TargetTransformInfo.h
  llvm/include/llvm/Analysis/VectorUtils.h
  llvm/include/llvm/IR/DiagnosticInfo.h
  llvm/include/llvm/Support/TypeSize.h
  llvm/lib/IR/DiagnosticInfo.cpp
  llvm/lib/Transforms/Vectorize/LoopVectorizationPlanner.h
  llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
  llvm/lib/Transforms/Vectorize/VPlan.cpp
  llvm/lib/Transforms/Vectorize/VPlan.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D85794.284920.patch
Type: text/x-patch
Size: 102919 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200811/ebe2e10e/attachment-0001.bin>