[PATCH] D19088: [Draft] Possible mapping of DIBuilder in the C API

[Amaury SECHET via llvm-commits]

deadalnix added a comment.

Hey, I don't think this is ready to be merged, as I put it there in relation to http://reviews.llvm.org/D19037 .

Know on your points. Metadata used to be part of the value hierarchy but recently moved to their own hierarchy in LLVM. This allow for great resource reduction when emitting debug metadata. It came with the introduction of MetadataAsValue and ValueAsMetadata in order to bridge the 2 hierarchy. That means, in order to manipulate metadata as value, the metadata need to be wrapped in a value node and unwrapped with every method calls. I think it is worthwhile to get away from the MetadataAsValue all over the place as the resource consumption of all these extra nodes is huge, and kind of defeat the whole point of the new metadata API.

As it turns out, methods that generate metadata now return a value of MetadataAsValue kind. Method that expect metadata unwrap that node and get the metadata out of it. As it turns out, this is transparent as passing other kind of values won't work, except for LLVMMDNode which special case constants. I think this one specifically can be updated, but I do not think it is necessary for other functions as using them in a way that would be incompatible with the current scheme would be a runtime error already.

In fact, I used that patch in SDC as a drop in, and it works even with outdated header for that very reason.

I propose to move forward with that the following way:

- Introduce LLVMMetadataRef and update function to use it. Introduce new functions for these that would accept values other than metadata (namely the LLVMMDNode family of functions).
- Start mapping DIBuilder, maybe in another header with backward compatibility disclaimer, like for Orc (the metadata hierarchy is quite new and will be subject to frequent changes for a few release I'm sure).

Would that makes sense ?


http://reviews.llvm.org/D19088