More compact SFrames through deduplication
Tatsuyuki Ishi
ishitatsuyuki@gmail.com
Mon Jan 26 16:06:16 GMT 2026
I took the time to turn this into a full proposal:
https://github.com/ishitatsuyuki/binutils/blob/sframe2cframe/libsframe/packed-table.md
This is a PoC written with lots of assist from AI, but there is also a ./binutils/sframe2cframe tool
in the tree, that takes a binary with SFrame and outputs a CFrame formatted file. When
--chunk-dwarf is specified it also does the heuristics chunking described in the proposal. The
heuristics requires parsing .eh_frame.
Using some locally created eh_frame to SFrame converter, I gathered the size numbers on
libvulkan_radeon.so (~7MB .text) for Clang and GCC generated binaries:
- Clang fp: SFrame 394702 bytes, CFrame 146670 bytes
- Clang no-fp: SFrame 601900 bytes, CFrame 153561 bytes
- GCC fp: SFrame 511711 bytes, CFrame 174045 bytes
- GCC no-fp: SFrame 824558 bytes, CFrame 398175 bytes
Deduplication performs worse on GCC, which is because it schedules prologs/epilogs into regular
instructions. That said, the packed scheme yields a net benefit.
The proposed design also puts the burden on the linker to pack up the table. As long as chunking is
done beforehand by the compiler, the linker does not need to parse the FRE. It only needs to
parse the FDE table to do the bit packing. Deduplication can be done on FRE strings blindly.
Let me know about your thoughts on the trade-offs.
Tatsuyuki Ishi
> On Nov 9, 2025, at 1:35, Tatsuyuki Ishi <ishitatsuyuki@gmail.com> wrote:
>
> [markdown version available at https://github.com/ishitatsuyuki/compact-frame/blob/master/pre-proposal.md] <https://github.com/ishitatsuyuki/compact-frame/blob/master/pre-proposal.md%5D>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20260127/9fec6833/attachment-0001.htm>
More information about the Binutils
mailing list