diff options
author | Eli Friedman <efriedma@quicinc.com> | 2020-04-06 17:03:49 -0700 |
---|---|---|
committer | Eli Friedman <efriedma@quicinc.com> | 2020-04-06 17:03:49 -0700 |
commit | 68b03aee1a15678ab5b518148d5e75c9dc0436fd (patch) | |
tree | f839c1aad6785c8316dac773ad2033a6987af029 /llvm/lib/Target/ARM/Disassembler/ARMDisassembler.cpp | |
parent | 8f2d2a7cb46572d51a7dddcf151fb202e4abeb4d (diff) | |
download | llvm-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