search for: d12536

...hared 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 this isn't substantially more restrictive than what we...

...> > 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 VST, kee. > If there is a perf impact with the FNENTRY o...

...> > 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 VST, kee. > If there is a perf impact with the FNENTRY o...

...is *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 VST, kee. >> If there is...

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

...is *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 VST, kee. >> If there is...