[all-commits] [llvm/llvm-project] 68b03a: Remove SequentialType from the type heirarchy.

[Eli Friedman via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 68b03aee1a15678ab5b518148d5e75c9dc0436fd
      https://github.com/llvm/llvm-project/commit/68b03aee1a15678ab5b518148d5e75c9dc0436fd
  Author: Eli Friedman <efriedma at quicinc.com>
  Date:   2020-04-06 (Mon, 06 Apr 2020)

  Changed paths:
    M clang/lib/CodeGen/CGExprConstant.cpp
    M llvm/include/llvm/IR/Constants.h
    M llvm/include/llvm/IR/DerivedTypes.h
    M llvm/include/llvm/IR/GetElementPtrTypeIterator.h
    M llvm/include/llvm/IR/Type.h
    M llvm/lib/Analysis/BasicAliasAnalysis.cpp
    M llvm/lib/Analysis/ConstantFolding.cpp
    M llvm/lib/Analysis/ScalarEvolution.cpp
    M llvm/lib/Bitcode/Reader/BitcodeReader.cpp
    M llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
    M llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
    M llvm/lib/IR/ConstantFold.cpp
    M llvm/lib/IR/Constants.cpp
    M llvm/lib/IR/Core.cpp
    M llvm/lib/IR/Type.cpp
    M llvm/lib/Linker/IRMover.cpp
    M llvm/lib/Target/AMDGPU/AMDGPUPromoteAlloca.cpp
    M llvm/lib/Target/Hexagon/HexagonCommonGEP.cpp
    M llvm/lib/Transforms/IPO/ArgumentPromotion.cpp
    M llvm/lib/Transforms/IPO/GlobalOpt.cpp
    M llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
    M llvm/lib/Transforms/Scalar/SROA.cpp
    M llvm/lib/Transforms/Utils/FunctionComparator.cpp
    M llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
    M mlir/lib/Target/LLVMIR/ModuleTranslation.cpp

  Log Message:
  -----------
  Remove SequentialType from the type heirarchy.

Now that we have scalable vectors, there's a distinction that isn't
getting captured in the original SequentialType: some vectors don't have
a known element count, so counting the number of elements doesn't make
sense.

In some cases, there's a better way to express the commonality using
other methods. If we're dealing with GEPs, there's GEP methods; if we're
dealing with a ConstantDataSequential, we can query its element type
directly.

In the relatively few remaining cases, I just decided to write out
the type checks. We're talking about relatively few places, and I think
the abstraction doesn't really carry its weight. (See thread "[RFC]
Refactor class hierarchy of VectorType in the IR" on llvmdev.)

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