search for: metadata_block_id

...one with the METADATA_KIND records. When working on the implementation of this handling for the upstream patches, I am reassessing how to do this perhaps more robustly. A few options: 1) Should the two module-level blocks use different block ids since they hold different types of records? I.e. a METADATA_BLOCK_ID (holding the actual metadata) and a new METADATA_KIND_BLOCK_ID (for the metadata kind records). That way it is more obvious what the two separate blocks are for and it is also much more trivial to identify and skip just the former. 2) Should I simply continue to assume that we will have two METADA...

...// 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, > > VALUE_SYMTAB_BLOCK_ID, > METADATA_BLOCK_ID, > @@ -257,8 +257,9 @@ namespace bitc { > SYNCHSCOPE_CROSSTHREAD = 1 > }; > > - // The function body block (FUNCTION_BLOCK_ID) describes function bodies. It > - // can contain a constant block (CONSTANTS_BLOCK_ID). > + // The function body block (FUNCTION_BLOCK_ID a...

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