[RFC] zstd as a compression algorithm for LTO

Martin Liška mliska@suse.cz
Thu Jun 20 09:08:00 GMT 2019


Hello.

As mentioned by Honza, it's using cmake and to be honest I prefer to use a shared
library than a statically build library. Moreover, it's an optional requirement and
so that we don't have to include that to contrib/download_prerequisites.

I like the idea of marking of compression algorithm in 'LTO_header'. However,
we do compress the header as well. Proper solution would be to make a new
section .gnu.lto_.header where we'll put:
struct lto_header
{
  int16_t major_version;
  int16_t minor_version;
};

I don't see a reason why why should have that information in each LTO ELF section?

In the time being, I've written the code so that I fallback in decompression to zlib
if ZSTD detects that LTO bytecode was compressed with zlib. On the contrary, decompression
of zstd with zlib will end with:
lto1: internal compiler error: compressed stream: data error

I'm sending updated version of the patch that can properly detect zstd.

Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Add-optional-support-for-zstd.patch
Type: text/x-patch
Size: 7360 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20190620/9d790ad2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Configure-detection-for-zstd.patch
Type: text/x-patch
Size: 5988 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20190620/9d790ad2/attachment-0001.bin>


More information about the Gcc-patches mailing list