[llvm-commits] patch: mdnode .bc format change
Nick Lewycky
nicholas at mxc.ca
Mon Jul 20 22:33:24 PDT 2009
Devang Patel wrote:
> Nick,
>
> On Fri, Jul 3, 2009 at 9:19 PM, Nick Lewycky<nicholas at mxc.ca> wrote:
>> This patch implements the new MDNode on-disk format for .bc files which we
>> would use if we supported instructions in MDNodes.
>>
>> This format is plainly inefficient when MDNodes only contain constants, but
>> I don't want to release 2.6 with a legacy file format that we need to
>> support.
>>
>> In the current format we store the MDNodes in the Constants block with
>> references to the other constants by number.
>>
>> The new format mentions the MDNodes in the Constant block but stores no data
>> about them other than the fact they exist.
>
> Why not put MDNodes in METADATA_BLOCK ?
They are. Because they're constants they're numbered in the constant
block but that has no information about their contents.
We need them to be numbered in the constants block so that the
instructions which come thereafter have a value number to refer to.
You can think of the constants block as containing the 'forward
declarations' of the mdnodes to come. Then the instructions are listed
which may refer to any constants, then the metadata_block fills in the
full definitions of the mdnodes which may refer to the constants and
instructions.
> Other comments:
>
> - I think WriteMetadata() is going to write MDNode multiple times.
Never. The METADATA_BLOCK contains:
{ node size, value number 1, value number 2 ... }
for each MDNode. Note that only the depth=1 level of an MDNode is
included; any MDNodes it contains are referenced by value number. This
even handles circular references correctly.
> - Reusing ConstantPlaceHolder for Metadata is not a good idea, I've
> doubts that this will work. ConstantPlaceHolder is meant for
> ConstExprs.
It works fine :) If you like I can refactor it into a
MetadataPlaceHolder, but I don't see the benefit. What in particular are
you worried about (ie. why does it matter that ConstantPlaceHolder was
meant for ConstExprs)?
> I am moving in a direction where metadata is not derived from
> Constant. I will introduce new block in bitcode to hold metadata
> strings and nodes.
Okay. I assume this goes with removing the uniqueness property from MDNode?
Nick
More information about the llvm-commits
mailing list