search for: function_block

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

The enclosed patch adds documentation for the PARAMATTR_BLOCK, TYPE_BLOCK, and TYPE_SYMTAB_BLOCK records in the LLVM IR bitcode format. I have started documenting CONSTANTS_BLOCK and FUNCTION_BLOCK and will send patches when they are complete. -Peter- -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100520/39b61edf/attachment.html> -------------- next part -------------- A non-text attachment wa...

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

.... The common case for this is PHI nodes, but in larger 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...

...tic promotion in the phase-3 backend). THINLTO_FUNCTION_SUMMARY_BLOCK This block contains a record for each function available for importing. At a minimum, it holds the index into the THINLTO_MODULE_STRTAB_BLOCK of the module containing the function, as well as the bitcode offset of the function’s FUNCTION_BLOCK within that module. The THINLTO_MODULE_STRTAB_BLOCK index will be 0 in the per-module function summary, as that section does not exist yet, but will be non-zero in the combined index/summary file (see Bitcode Combined Function Summary section below). It also will be used to hold information about t...

...ct: Re: [LLVMdev] Enable Detailed Output llvm-bcanalyzer ajonwa, It will provide some of the information you're seeking, but not all. Here's a partial dump from one of the bitcode test cases: ./llvm-bcanalyzer ~/llvm/test/Bitcode/spirit-llvm-2.9.ll.bc 2>&1 | less Block ID #12 (FUNCTION_BLOCK): Num Instances: 4370 Total Size: 3696434b/462054.25B/115513W Percent of file: 28.9617% Average Size: 845.87/105.73B/26W Tot/Avg SubBlocks: 5365/1.227689e+00 Tot/Avg Abbrevs: 0/0.000000e+00 Tot/Avg Records: 65553/1.500069e+01 Percent Abbrevs: 32.9809% Record Histogram: Count # Bits % Abv...

...backend). > THINLTO_FUNCTION_SUMMARY_BLOCK > > This block contains a record for each function available for importing. At > a minimum, it holds the index into the THINLTO_MODULE_STRTAB_BLOCK of the > module containing the function, as well as the bitcode offset of the > function’s FUNCTION_BLOCK within that module. The > THINLTO_MODULE_STRTAB_BLOCK index will be 0 in the per-module function > summary, as that section does not exist yet, but will be non-zero in the > combined index/summary file (see Bitcode Combined Function Summary section > below). It also will be used to hold...

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