search for: function_block_ids

Hi Jan, > I've been looking into how to make llvm bitcode files smaller. There is one > simple change that appears to shrink linked bitcode files by about 15%. See > this spreadsheet for some rough data: > > https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E the improvement is wonderful! ... > In any case, the patch is attached if

Hi all, I've been looking into how to make llvm bitcode files smaller. There is one simple change that appears to shrink linked bitcode files by about 15%. See this spreadsheet for some rough data: https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E The change is in how operand ids are encoded in bitcode files. Rather than use an "absolute

...single string table, which in multi-module bitcode files would be shared between modules.) This *almost* allows us to remove the global (top-level) VST entirely, if not for the function offset in the FNENTRY record. However, this offset is not actually required because we can scan the module's FUNCTION_BLOCK_IDs as we were doing before http://reviews.llvm.org/D12536 (this may have a performance impact, so I'll measure it first). Assuming that performance looks good, does this seem reasonable to folks? Thanks, -- -- Peter [0] This means that no GlobalValue or comdat name can contain a null, but thi...

...ch in > multi-module bitcode files would be shared between modules.) > > This *almost* allows us to remove the global (top-level) VST entirely, if > not for the function offset in the FNENTRY record. However, this offset is > not actually required because we can scan the module's FUNCTION_BLOCK_IDs > as we were doing before http://reviews.llvm.org/D12536 (this may have a > performance impact, so I'll measure it first). > > Assuming that performance looks good, does this seem reasonable to folks? > > > > I rather seek to have a symbol table that entirely replace the...

...ch in > multi-module bitcode files would be shared between modules.) > > This *almost* allows us to remove the global (top-level) VST entirely, if > not for the function offset in the FNENTRY record. However, this offset is > not actually required because we can scan the module's FUNCTION_BLOCK_IDs > as we were doing before http://reviews.llvm.org/D12536 (this may have a > performance impact, so I'll measure it first). > > Assuming that performance looks good, does this seem reasonable to folks? > > > > I rather seek to have a symbol table that entirely replace the...

...-module bitcode files would be shared between modules.) >> >> This *almost* allows us to remove the global (top-level) VST entirely, if >> not for the function offset in the FNENTRY record. However, this offset is >> not actually required because we can scan the module's FUNCTION_BLOCK_IDs >> as we were doing before http://reviews.llvm.org/D12536 (this may have a >> performance impact, so I'll measure it first). >> >> Assuming that performance looks good, does this seem reasonable to folks? >> >> >> >> I rather seek to have a symbol...

...-module bitcode files would be shared between modules.) >> >> This *almost* allows us to remove the global (top-level) VST entirely, if >> not for the function offset in the FNENTRY record. However, this offset is >> not actually required because we can scan the module's FUNCTION_BLOCK_IDs >> as we were doing before http://reviews.llvm.org/D12536 (this may have a >> performance impact, so I'll measure it first). >> >> Assuming that performance looks good, does this seem reasonable to folks? >> >> >> >> I rather seek to have a symbol...