diff options
author | Alex Langford <alangford@apple.com> | 2023-05-09 14:34:20 -0700 |
---|---|---|
committer | Alex Langford <alangford@apple.com> | 2023-05-10 11:17:30 -0700 |
commit | 2ec334dc7b7329c6b71faa037a0d926e8e130c20 (patch) | |
tree | 836eeb0dc8f1ec3e64ca3462295c5a91dd462fc7 /llvm/lib/Transforms/Utils/LoopUnrollAndJam.cpp | |
parent | 33314693f536a66390b0e022f2f00be94de5b06e (diff) | |
download | llvm-2ec334dc7b7329c6b71faa037a0d926e8e130c20.zip llvm-2ec334dc7b7329c6b71faa037a0d926e8e130c20.tar.gz llvm-2ec334dc7b7329c6b71faa037a0d926e8e130c20.tar.bz2 |
[lldb][NFCI] Replace dw_form_t with llvm::dwarf::Form
LLDB currently defines `dw_form_t` as a `uint16_t` which makes sense.
However, LLVM also defines a similar type `llvm::dwarf::Form` which is
an enum backed by a `uint16_t`. Switching to the llvm implementation
means that we can more easily interoperate with the LLVM DWARF code.
Additionally, we get some type checking out of this: I found that
DWARFAttribute had a method called `FormAtIndex` that returned a
`dw_attr_t`. Although `dw_attr_t` is also a `uint16_t` under the hood,
the type checking benefits here are undeniable: If this had returned a
something of different signedness/width, we could have had some bad
bugs.
Differential Revision: https://reviews.llvm.org/D150228
Diffstat (limited to 'llvm/lib/Transforms/Utils/LoopUnrollAndJam.cpp')
0 files changed, 0 insertions, 0 deletions