search for: fnentry

...le that has its own STRTAB_BLOCK. > (Normally bitcode files would contain a 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, doe...

...ated with "llvm-cat -b". > (Normally bitcode files would contain a 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, doe...

...continue to be concatenated with "llvm-cat -b". (Normally bitcode files would contain a 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 t...

Hi all, I updated the patches to remove the native object wrapper format. As suggested we will work on getting the ThinLTO framework in place using bitcode first, and then work on adding the native object support. As noted in this RFC and in the associated patch D11722, for now I have empty ThinLTO blocks with no records, since I wanted to get feedback on the overall block design first. The RFC

...-cat -b". >> (Normally bitcode files would contain a 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 perform...

...-cat -b". >> (Normally bitcode files would contain a 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 perform...