search for: function_block_id

...vm/Bitcode/LLVMBitCodes.h b/include/llvm/Bitcode/LLVMBitCodes.h > index c1dc190..6c81739 100644 > --- a/include/llvm/Bitcode/LLVMBitCodes.h > +++ b/include/llvm/Bitcode/LLVMBitCodes.h > @@ -33,9 +33,9 @@ namespace bitc { > UNUSED_ID1, > > CONSTANTS_BLOCK_ID, > - FUNCTION_BLOCK_ID, > + FUNCTION_BLOCK_ID, // Deprecated in favor of FUNCTION_BLOCK_ID_REL FUNCTION_BLOCK_ID_REL -> FUNCTION_BLOCK_REL_ID Is there any point in having this on a per-function basis, why not have it be per-module? > > - UNUSED_ID2, > + FUNCTION_BLOCK_REL_ID, > > VA...

...tests fewer bits *overall* are used for INST_PHI. - Doesn't help with constant operands. Their ids will now constantly change... - To retain backward compatibility with old bitcode files, I ended up using up a new bitc value "bitc::FUNCTION_BLOCK_REL_ID" vs the existing "bitc::FUNCTION_BLOCK_ID". Are there known problems with this scheme? Are there other ideas that have been floated around for reducing the size of bitcode files? In any case, the patch is attached if there is interest... If you want to try out the patch, you can toggle between the new and old encoding by using the f...

...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 th...

...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 th...

...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 th...

...-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 symbo...

...-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 symbo...