aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Target/ARM/Disassembler/ARMDisassembler.cpp
diff options
context:
space:
mode:
authorEli Friedman <efriedma@quicinc.com>2020-04-06 17:03:49 -0700
committerEli Friedman <efriedma@quicinc.com>2020-04-06 17:03:49 -0700
commit68b03aee1a15678ab5b518148d5e75c9dc0436fd (patch)
treef839c1aad6785c8316dac773ad2033a6987af029 /llvm/lib/Target/ARM/Disassembler/ARMDisassembler.cpp
parent8f2d2a7cb46572d51a7dddcf151fb202e4abeb4d (diff)
downloadllvm-68b03aee1a15678ab5b518148d5e75c9dc0436fd.zip
llvm-68b03aee1a15678ab5b518148d5e75c9dc0436fd.tar.gz
llvm-68b03aee1a15678ab5b518148d5e75c9dc0436fd.tar.bz2
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
Diffstat (limited to 'llvm/lib/Target/ARM/Disassembler/ARMDisassembler.cpp')
0 files changed, 0 insertions, 0 deletions