aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Transforms/Utils/LoopUnroll.cpp
diff options
context:
space:
mode:
authorAlex Langford <alangford@apple.com>2023-05-09 14:34:20 -0700
committerAlex Langford <alangford@apple.com>2023-05-10 11:17:30 -0700
commit2ec334dc7b7329c6b71faa037a0d926e8e130c20 (patch)
tree836eeb0dc8f1ec3e64ca3462295c5a91dd462fc7 /llvm/lib/Transforms/Utils/LoopUnroll.cpp
parent33314693f536a66390b0e022f2f00be94de5b06e (diff)
downloadllvm-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/LoopUnroll.cpp')
0 files changed, 0 insertions, 0 deletions