diff options
author | Pavel Labath <pavel@labath.sk> | 2025-08-12 10:10:45 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-08-12 10:10:45 +0200 |
commit | 66aa46da6c2f18d8e7493bc2105abef0af4a7b98 (patch) | |
tree | 601dd26c529f0988ebd6ed5bb7209db2beee15c5 /llvm/lib/Transforms/Utils/LoopUtils.cpp | |
parent | 9e8f7acd2b3a71dad473565a6a6f3ba51a3e6bca (diff) | |
download | llvm-66aa46da6c2f18d8e7493bc2105abef0af4a7b98.zip llvm-66aa46da6c2f18d8e7493bc2105abef0af4a7b98.tar.gz llvm-66aa46da6c2f18d8e7493bc2105abef0af4a7b98.tar.bz2 |
Reapply "[Object] Parsing and dumping of SFrame Frame Row Entries" (#152650) (#152695)
This reapplies #152650 with a build fix for clang-11 (need explicit
template parameters for ArrayRef construction) and avoiding the
default-in-a-switch-covering-enum warning. It also adds two new tests.
The original commit message was:
The trickiest part here is that the FREs have a variable size, in two
(or three?) dimensions:
- the size of the StartAddress field. This determined by the FDE they
are in, so it is uniform across all FREs in one FDE.
- the number and sizes of offsets following the FRE. This can be
different for each FRE.
While vending this information through a template API would be possible,
I believe such an approach would be very unwieldy, and it would still
require a sequential scan through the FRE list. This is why I'm
implementing this by reading the data into a common data structure using
the fallible iterator pattern.
For more information about the SFrame unwind format, see the
[specification](https://sourceware.org/binutils/wiki/sframe) and the
related
[RFC](https://discourse.llvm.org/t/rfc-adding-sframe-support-to-llvm/86900).
Diffstat (limited to 'llvm/lib/Transforms/Utils/LoopUtils.cpp')
0 files changed, 0 insertions, 0 deletions